Это наверное больше про текущие проблемы….

Неудобства:
1. Для карточки ОС даты начала и окончания амортизации действуют на всю карточку, а не на тип амортизации
2. Невозможно хранить историю дооценки ОС (только начальная и конечная цифра)
3. Если контрагент является и поставщиком и покупателем, корректировать его карточку нужно в двух местах, Нет отчетов, которые сводили бы данные по покупателю и поставщику в единый отчет. Как для покупателя, так и для поставщика существует отдельный справочник банковских кодов.
4.Поиск контрагента происходит по набору первых символов, а не по набору любых символов.
5.Нет нормальной системы учета взаимоотношений с контрагентом, в разрезе договоров, использование учетного измерение договор является частичным решением проблемы.
6.При частичном закрытии позиций не происходит выделение НДС
7.При закрытии валютных позиций проводка по переоценке суммируется к основной проводке
8.Бюджетировать можно только счет в сочетании с учетными измерениями, но не комбинацию учетных измерений.
9. Невозможно настроить систему так, чтобы в компании, принимающей данные можно проводить переоценку без переоценки консолидирующей компании.
10. Аллокация делит каждую проводку, а не итоги по счету и комбинации учетных измерений.

Спасибо за внимание

Уважаемые гуру Scala- будет интересно ваше мнение

Каждое измерение, включая счет, не более 12 символов каждое.
Счет + первые три измерения в сумме не более 30 символов, хотя 4 * 12 = 48, т.е. структуру приходится кроить под эти требования.

А если использовать Balance-based Compound Periodic Allocations (сложные периодические распределения) с условиями debit / credit / both ? Сам не пробовал, но вдруг подойдет?

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

>> просто, на мой взгляд у системы, которая не может решить проблемы такого уровня несколько лет нет будущего

Году в 1993 один человек сказал, что Скале на нашем рынке жить осталось от силы год (примерно по тем же причинам), потом он работал там консультантом, потом ушел к клиенту. Так что не всегда такие прогнозы оказываются точны. Epicor / Scala сейчас вендор номер 11 в мире, и полмира отдали под iScala 2.2. Не думаю, что уже завтра система перестанет существовать.
В России очень пассивные пользователи (это опять не я сказал) по сравнению с другими странами, и поэтому предложение AAV по лоббированию своих интересов вполне актуально. Только разговаривать имеет смысл о весьма конкретных недостатках, которые не покрывает наличие, например, VBA + UDDB.