Полностью согласен с Владимиром 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, который в соответствующей табличке пропишет соответствующие данных в одно поле их можно удалить из интерфейса АЛЬФа. Я считаю, что это глюк функционала. Т.к. мы решили пока не обновлять версии, то эту проблему решаем сверочными отчетами.