Показать сообщение отдельно
Старый 30.07.2003, 13:30   #4  
Pavel is offline
Pavel
SAP
SAP
 
2,760 / 239 (13) ++++++
Регистрация: 14.12.2001
Адрес: Moscow
Re: Проблемы Scala очень интересно как реализуются подобные ситуации в других системах
Детально про "другие" системы

Цитата:
Изначально опубликовано 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 с параметрами аналитика/без.