Обсуждаем:
1. методы внедрения
2. подводные камни, баги и обходы
3. расширение функциональности (в том числе собственными средствами)
дополнительные программы и утилиты, Oracle пакеты к системе АЛЬФА
4. как сделать ... как у вас сделано... как лучше сделать...

surrealistинтересно, кто-нибудь продолжает обновлять версии(имею ввиду тех,кто купил двойку)? Если уже намыкались, то на каких остановились?
Мы остановились на 2.4.04.000 По началу обновляли, но исправляя указанные нами ошибки в новых версиях появлялись новые в неожиданных местах. Мы решили, что лучше ошибки знать и пытаться обходить, чем каждый раз натыкаться на новое-непознанное:) и в связи с этим прекратили обновлять версии. Сейчас как я знаю Информконтакт готовит или уже выпустил версию 4 Альфы, но то что я видел было сыровато. Задумка там конечно помощьнее весьма и хотелось бы на ней работать, но я думаю, что через года 2 -3 она отладится и тогда может быть. Еще настораживает тот факт, что соблюдена ограниченная совместимость 4 и 2. Так что не так-то просто на нее перейти.

voiceПоделитесь опытом - как печатаете отчеты, документы из Alfa?
Мб есть готовые шаблоны для EXCEL?

Есть немного готовых шаблонов Excel. Общий принцип форматирования: Т.к. при экспорте в Excel Альфа создает файл из двух листов: 1. сам отчет 2.
имеет вид:
4 Строк заголовка
11 Строк данных
44 Колонок данных
, то создается файл-шаблона в котором пишется процедура Лист1: Private Sub Worksheet_Activate() в которой считываются данные из листа 2 и производится форматирование Листа 1
Есть разумеется недостаток такого подхода: форматирование запускается каждый раз при активации листа. Альтернативой как я понимаю, предполагалась опция диалога экспорта в Excel "Запустить макрос ALFARun после печати" , но она не работает и как сообщили нам в службе поддержки, что эта возможность отключена за ненадобностью и включена не будет.
пишите на vilkelis@spp.ru всем желающим вышлю шаблоны для Account

voiceПоделитесь опытом - как печатаете отчеты, документы из Alfa?
Мб есть готовые шаблоны для EXCEL?
Что сразу бросилось в глаза при изучении АЛЬФЫ так это отсутствие настройки форм диалогов запроса параметров для формирования произвольных отчетов. Все генераторы отчетов: A3 Reports, Cristall Reports, Centura Report Builder не обладают или обладают лишь примитивными средствами из создания. Универсальные отчеты системы АЛЬФА конечно некоторый выход из положения, но бухгалтеру или кладовщику нужны отчеты конкретной фиксированной формы с небольшим набором опций. Мы как выход из этой ситуации (ну и из другий) создали собственную систему для разработки отчетов RvAlgo.

surrealistинтересно, кто-нибудь продолжает обновлять версии(имею ввиду тех,кто купил двойку)? Если уже намыкались, то на каких остановились?
А как у Вас ситуация с обновлениями версий?

Владимир112 Vilkelis

Команда внедрения ДОЛЖНА очень хорошо знать pl/sql и разбираться структуре БД, без этого внедрения не будет. Для внедрения ALFA нормальная ситуация, когда все сидят и переписывают код ИК. Настоять на том, чтоб проводки были написаны на pl/sql а не на встроенном языке.

Разумеется команда должна знать PL/SQL. Как же без него с Oracle работать. А зачем настаивать? В типовой операции в Альфе есть execute immediate и следовательно можно без проблем формировать проводки, вызывая процедуры пакетов. Но полностью переписывать код ИК смысла нету. Account у них, я считаю вообще очень хороший. Payment у нас встал как родной. Вот со Stock сложнее, но тоже пока выкручиваемся. Только с формированием отчетов у них большие проблемы. Вот единственное что и переписали.

surrealist Vilkelis создали собственную систему для разработки отчетов RvAlgo.

что это за зверь?
Зверь такой:
Создавался для создания систем отчетности для АЛЬФы в частности ну и для любой базы данных вообще. Работает с базами данных через кучу драйверов (ADO,dbExpress, ADS, DOA, BDE, ODBC). С Oracle работает через DOA (Direct Oracle Acces) Позволяет создавать древовидное меню для пользователей с различными режимами. В основном режимами запуска отчетов. Имеет три встроенных банд-ориентированных визуальных генератора отчетов и один визуальный генератор OLAP кубов (по нехнологии MOLAP). Имеет встроенный интерпретатор языка Pascal. Имеет возможности создавать достаточно сложные формы диалогов а так же поддерживает технологию "погружения" при создании отчетов.
является отдельным прилождением с авторизацией доступа к функциям.Все настройки хранит в базе данных в дереве произвольной структуры, что дает возможность упорядочивать проект. Со временем функциональность системы была расширена и теперь система может загружать данные из бюбых форматов в любые, а так же можно с помощью системы создавать режимы редактирования данных. Описание можно найти на www.rvilk.com. Самое интересное в этой системе, что можно создавать стандартные конфигурации для АЛЬФы (типа конфигураций 1С) что у нас и есть.

Владимир11
Настоять на том, чтоб проводки были написаны на pl/sql а не на встроенном языке.
Я считаю, что это весьма спорный вопрос стоит ли это делать. Все-таки какой ни корявый язычек встроен в Альфу в качестве парсера проводок, но пользоваться им довольно сносно (хотя в документации половина синтаксиса и функций не описаны). Тем более вопрос написания проводок это скорее вопрос не внедрения, а сопровождения. А сопровождающий может и не знать PL/SQL.

Владимир11
Написание проводок это вопрос внедрения (если есть требование внедрить БУ).
Если сопровождение не будет знать PL/SQL и как админить oracle, то грош цена такому сопровождению. И на нормальной работе можно поставить жирный крест. Это мое мнение, проверенное практикой.

Ну не только же админы Оракла сопровождают корпоративки. А вообще идея писать проводки на PL конечно же нормальная. Но как-то мы без этого уже долго обходимся и проблем не возникает. Хотя похоже скоро возникнет такая задача (в связи с вводом в эксплуатацию автоматической книгой покупок-продаж).

Владимир11[quot Vilkelis] Система работает достаточно надежно, в том смысле, что особых проблем с данными нет, однако есть большие проблемы с функционалом. Скажите а 20 счета сколько времени у вас закрываются?
Да. Полностью согласен. Система работает действительно в плане данных на удивление надежно, ну и проблемы с функционалом конечноже:) Но эти вещи должны быть решены на этапе внедрения.
20-е закрываются около секунды (закрытие закрытию рознь:)).

Народ! Кто как решает проблему с фиксированным интерфейсом АЛЬФы? Или это не проблема?

Владимир11
В делфевых вроде проблем нет, за некоторым исключением... сейчас не знаю, а раньше я дописывал механизм компиляции объектов (ну очень криво он был написан) =))
Вы на 4-ке работаете? На каких модулях? Сильно кривые или жить можно?

Владимир112 Vilkelis

Я не работал... я внедрял, правда уже пол года с того момента прошло, но:

4.0 делфевые модули кривые, модуль ОСов был переписан =)) Сток не рабочий... Контракт был тоже переписан... Конфигуратор дописан =)) вообще c делфевыми модулями работать приятнее и прощее, а ошибки и интерфейс поправить можно.
Я смотрел 4 модуль Работа с подотчетниками. То что мне дали было вообще не рабочее. Но так же заметил, что работать с ними приятней точно. Переписан это как? У них в 4-ке что-ли полноценная среда разработки? Если честно я не уловил принципа каким образом 4-ка построена. У тебя случаем нету ли каких нибудь методичек, которые могли бы пролить свет на принцип построения 4-ки?

Ну а вообще в целом на 4-ку можно заточить чтобы нормально работала?

Полностью согласен с Владимиром 11. Качество сопровождения и наличие документации к системе совершенно не устраивает. Получать глупые ответы на конкретные вопросы и дурацкие требования выслать дамп базы данных уже нам надоело и месяца 4-ре мы уже не обращаемся в службу поддержки. Сдается, что оно так и было задумано:) Еще не устраивает тот факт, что в 4-ке соблюдена весьма ограниченная совместимость с 2-ой. При изучении 4-ки я сделал вывод, что по большому счету 4-ка и 2-ка на одной базе данных работать не могут.

FlexxЯ так понимаю что все присутсвующие если с четврёркой и работали то с самыми ранними версиями, уровня beta.
Согласен, были сыроваты, как и любая beta в принципе. В настоящий момент ситуация принципиально иная (с документацией кстати тоже) ряд проектов на четвёрке спокойно работает. Так что кому интересно - обращайтеся в офис. Вообще интересно почему ИК продает beta версии ERP:)? Как могло получиться так что большие заводы с серьезными программистами, у которых всегда стоят последние полностью пропатченные версии Windows, Linux, Unix взяли и стали работать вдруг на сырой версии на которой крупными буквами написано BETA? Мы пробовали ставить модуль Advance 4.0.3.0. Который нам прислал ИК. Заметьте что BETA в номере версии (так же как и в окне О программе) не встречается. Так помучившись, реализовали тот же функционал в Stock 2.

ln
То Vilkelis Не моглы бы вы сказать основаясь на чем вы говорите что 2-рые модули не смогут работать на одной базе с 4-верошными? Просто я наблюдал обратную ситуацию когда такая связка очень да же неплохо работала и считал что как раз с приемственностью тут все нормально хотя своя кривизна конечно есть.

Я основываюсь на утверждении специалистов ИК. Для того чтобы установить 4-ку необходимо произвести ряд Update базы данных, и как я понял, не совсем совместимых с 2. Сам пробовал запустить модуль Advance 4.0.3.0 в одной базе с 2. - Сыполись ошибки. Глубоко конечно этот вопрос не копал - некогда: надо 2-ку внедрять, а 4-ка еще не куплена. Конечно в Альфе есть огромный плюс: то что база данных открытая и по этому поводу можно прикрутить почти все почти ко всему (правда это "почти" местами сильно мешает, хотелось бы видеть больше серверного функционала). Но мне как внедренцу хотелось бы просто выполнить инструкции по установке программы и чтобы после этого она работала и не убила мои данные, а не изучать каждый раз скрипт SQL на совместимость со старыми настройками. Если сейчас ситуация изменилась - то я только рад.

Хочу выяснить отношение народа к такому факту:
В Альфе как известно бух. проводки формируются модулем Trans. Т.е. при создании документа проводки автоматически не создаются. Для того чтобы создать проводки необходимо выполнить ряд действий в модуле Trans. С одной стороны данная концепция соответствует принципу разделения оперативного и бухгалтерского учета (т.е. например первичку вводит оператор, а проводки формирует бухгалтер) , но:
1. Обычно оператор и бухгалтер - один человек. Зачем разделять эти функции, если формирование проводок четко происходит по информации из документа? Достаточно проверить документ: документ введен верно - следовательно и проводки сформированы правильно (бухгалтер в этом случае получается лишним звеном)
2. Всегда стоит задача проверить на соответствие введенного документа и бух. проводок, а в модуле Trans можно проводки при формировании править ручками
3. В Альфе нет ни одного режима простого просмотра с документа его проводок и с проводок, документа, породившего их.
4. Ну если уж разрешили при генерации проводок их править ручками, то уж информацию что проводки подправлены руками просто необходимо где-то прописывать и показывать, а то обыденная ситуация: настраиваешь типовую операцию, а через неделю приходит к тебе разъеренный бухгалтер и говорит, что твоя типовая операция создает не правильно проводки:)

Поэтому я бы исключил модуль Trans как класс, т.к. не вижу в нем смысла. Может до меня не дошла какая-то великая идея этого разделения?

Интересно узнать другие мнения по вопросу связи документа и проводк.

brainwashedПростите, влезу...
1.Что это за ERP, где бухгелтер вводит документ? По идее документы должны стекаться из других блоков, бухгалтер же должен проверять их правильность и просто проводить.
Разделение должно существовать. см. п.1
Так оно и предусмотрено, но с одной оговоркой: есть отдельный модуль, в котором проводятся документы. И как я считаю есть большой недостаток в том что нет четкой связки документ - его проводки. Т.е. механизма позволяющего не проверять правильность бух. проводок по уже проверенным документам. Нет так же механизма и проверки. Я думаю, что этим страдает не только АЛЬФА:)

brainwashedПеречитал все про Альфу ещё раз. Не понятно, зачем откатывать какие-то определенные проводки по ОСам. Разве они откатываются не от первичного документа? А сами по-отдельности? Или это опять в тему неясной связи проводок с документом?

По поводу ОСов я не знаю. А по поводу документов Payment (Касса,Банк) при удалении проведенного документа программа вежливо спрашивает пользователя: а не желаете ли вы после удаления документа еще и проводки откатить? Половина пользователей конечто же отвечает "НЕТ. Я не знаю что такое проводки, поэтому их удалять и не собираюсь." После чего эти проводки нельзя вообще удалить из интерфейса системы. Т.к. они считаются принадлежащими модулю Payment. Только после выполнениия update sql, который в соответствующей табличке пропишет соответствующие данных в одно поле их можно удалить из интерфейса АЛЬФа. Я считаю, что это глюк функционала. Т.к. мы решили пока не обновлять версии, то эту проблему решаем сверочными отчетами.