Проблемы Scala очень интересно как реализуются подобные ситуации в других системах

[Leshic]

Ограничения:
1.Ограничение на число валют (всего 30 валют), документы по продажам формируются в 6 валютах
2. Учетная строка ограничивается 50-ю символами, максимальное число учетных измерений –9
3. Для документов предоплаты возможно всего 10 типов документов
4. Ограничения на название, например полное название контрагентов всего 50 символов

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

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

[Pavel]

Имел возможность столкнуться со многими из указанных проблем на инсталляции SCALA в одной из крупнейших отечественных телекомпаний и могу продолжить данный список. Полагаю, что проблемы большей частью из-за устаревшего функционала и технологии системы (закрытости структуры данных и бизнес логики). На формальный запрос специалисты компании SCALA предложили "обходные пути" решения проблем.

Практически все популярные отечественные и западные системы имеют открытый код, что позволяет разработчикам, внедренцам и клиентам эффективно решать соответсвующие задачи (локализацию, разработку функционала, кастомизацию, поддержку и т.п.)

[Leshic]

крупнейших отечественных телекомпаний - а на какой?

[Pavel]

Детально про "другие" системы

Цитата:

Изначально опубликовано Leshic
1.Ограничение на число валют (всего 30 валют), документы по продажам формируются в 6 валютах

ограничения нет

Цитата:

Изначально опубликовано Leshic
2. Учетная строка ограничивается 50-ю символами, максимальное число учетных измерений –9

количество измерений не ограничено или расширяется путем модификации

Цитата:

Изначально опубликовано Leshic
4. Ограничения на название, например полное название контрагентов всего 50 символов

Легко настраивается по требованию клиента

Цитата:

Изначально опубликовано Leshic
1. Для карточки ОС даты начала и окончания амортизации действуют на всю карточку, а не на тип амортизации

В разных системах по-разному, во всех мелкософтовских существует возможность ведения нескольких книг амортизации (соответственно с разными датами).

Цитата:

Изначально опубликовано Leshic
2. Невозможно хранить историю дооценки ОС (только начальная и конечная цифра)

Все переоценки хранятся в операциях по карточке ОС как отдельные операции.

Цитата:

Изначально опубликовано Leshic
3. Если контрагент является и поставщиком и покупателем, корректировать его карточку нужно в двух местах, Нет отчетов, которые сводили бы данные по покупателю и поставщику в единый отчет. Как для покупателя, так и для поставщика существует отдельный справочник банковских кодов.

Стандартный подход в ERP системах иметь раздельные карточки дебиторов/кредиторов и банковских реквизитов. Однако как правило:
- существует возможность установить связь между дебиторской и кредиторской карточками
- создать любые отчеты произвольной формы
- кастомизировать интерфейс работы с данными контрагентов
- банковские реквизиты хранятся в единном справочнике с четким разделением записей: реквизиты собственной компании, реквизиты дебиторов, реквизиты кредиторов. Далее получить необходимую отчетность интерфейс "дело техники"

Цитата:

Изначально опубликовано Leshic
4.Поиск контрагента происходит по набору первых символов, а не по набору любых символов.

кроме указанного выше есть возможность контекстного поиска, фильтров по любым полям карточки дебитора/кредитора

Цитата:

Изначально опубликовано Leshic
5.Нет нормальной системы учета взаимоотношений с контрагентом, в разрезе договоров, использование учетного измерение договор является частичным решением проблемы.

Не согласен. В SACLA как в любой другой системе есть заказы и закупки, позволяющие реализовать операции по контрагентам/договорам. Хотя необходимо отметить, что и там есть ограничения по функциональности (частичные отгрузки проводятся отдельными заказами/закупками).

Цитата:

Изначально опубликовано Leshic
6.При частичном закрытии позиций не происходит выделение НДС

В аксапте с этим тоже проблема. Более того в общем случае возможна ситуация, когда по фактуре идет несколько позиций с разными кодами НДС (т.е. разные бух. субсчета учета 19-е и возмещения 68-е, а также разными ставками 20%, 10%, 0%). В этом случае при частичной оплате и возмещении НДС возникает сложность какой из НДС возмещать в первую очередь, с какого 19-го счета на какой 68-й и т.п.
Т.е. по сумме возмещения все известно, а по аналитике возникают альтернативные варианты. Вопрос частичного возмещения тонкий и требует точной и тщательной проработки.

Цитата:

Изначально опубликовано Leshic
7.При закрытии валютных позиций проводка по переоценке суммируется к основной проводке

Современные системы по каждой переоценке делают отдельную запись, которая на указанный момент времени (т.е. курс) делает адекватной стоимость валютных сумм.
Причем позволяется иметь на одном счете разные валюты, проводить переоценку одной или всех валют, сразу или раздельно и т.п.

Цитата:

Изначально опубликовано Leshic
8.Бюджетировать можно только счет в сочетании с учетными измерениями, но не комбинацию учетных измерений.

такого рода ограничения только в скале

Цитата:

Изначально опубликовано Leshic
9. Невозможно настроить систему так, чтобы в компании, принимающей данные можно проводить переоценку без переоценки консолидирующей компании.

Исключительно прикол SCALA. После трансляции, например, в аксапте можно провести переоценку валюты без последствий для базы источника. Трансляцию можно провести с автоматической переоценкой (меньше аналитики, т.к. будет одна сумма на разнице трансляции, но тот же результат для состояния счетов).

Цитата:

Изначально опубликовано Leshic
10. Аллокация делит каждую проводку, а не итоги по счету и комбинации учетных измерений.

Периодической аллокации в мелкософтовских системах нет вообще, поэтому с проблемой большого количества проводок пользователи не сталкиваются. Есть только текущая аллокация (т.е. в момент создания записи в ГК). В принципе есть опыт создания и успешной эксплуатации функций allocation&closing с параметрами аналитика/без.

[Pavel]

Цитата:

Изначально опубликовано Leshic
крупнейших отечественных телекомпаний - а на какой?

Не могу публично дать такую информацию, т.к. это автоматически создает возможность "проблем" у клиента с поставщиком.

[Leshic]

Павел!
может вы меня помните?
я- Засимов Алексей, помните такого?

[Pavel]

Цитата:

Изначально опубликовано Leshic
я- Засимов Алексей, помните такого?

Привет, Алексей, очень хорошо помню. Согласуй с руководством визит в вашу "родительскую" компанию на предмет изучения опыта внедрения и эксплуатационных характеристик системы Navision XAL 3.5.

[Leshic]

Рад встрече.
Интеллектуальная прослойка значит тонка.
Очень хороший форум по продуктам MBS!
Павел! А вы случайно про Скалу никакого подобного форума не знаете?
Мы тоже на месте не стоим и очень сильно продвинулись.
Так что, шар ввертится прогресс движется

[Pavel]

Попробуй зайти на ERP форум и запустить поиск по слову "SCALA".
http://www.erpforum.ru/forum/search....A0%A0%A0%A0%A0