foxwizarddabino- ну и в результате отчеты генерятая часами, потом пользователи дообрабатывают их в экселе (если удается открыть файл)

За такое в нормальной компании - увольнение....
По некоторым пунктам нормальность компании ваще не при чем. Скажем так - по основным пунктам. Например, использование констант в коде на скорость не влияет, так же как и нечитаемость имен. А все остальное - в основном проблемы архитектуры и языковых средств, реализованных в ERP.

Вообще (это моя точка зрения), ERP возникли как средство автоматизации бизнеса. Но очень скоро до производителей дошло, что одними настройками (галочками в формах) не обойтись, стали придумывать свои языки. Я даже не говорю про уровень языков и сред программирования... с содроганием вспоминаю C-AL(интересно, с 4-й версии что-нибудь в лучшу сторону поменялось?). Проблема в том, что этит языки она делали на своем уровне, вне СУБД. Ну и возникло деление по уровням. которое преподносится как типа круто (и местами оно может так и есть, например, говорят, что, вроде, масштабировать легче). Но КМК это ведет в тем проблемам, про которые тут написано, и проблем больше чем преимуществ.

Очень много маркетинга. Одной конторе втюхали тот же нафижн со словами, что де отчеты в Excel так же просто выводить, как в Access'e, и ваще - это тот же ассесс адаптированый под бизнес . А по факту , для каждого отчета надо отдельный выводить в Excel прописывать со всеми навижнскими танцами. Но даже если бы Навик был бы так же удобен как среда VBA , то от принципиальных проблем, связанных с разделением по уровням, это не избавит.

dabinoВсем большое спасибо за комментарии и мнения (которые разделились).

из свежих приколов: при построении отчета от пользователя требуется указать, сколько же дней в этом феврале - 28 или 29...
Это никакой архитектурой не исправишь :).

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

instantIzya...
это стандартная ситуация, когда требуют поделить неделимое, нави-разработчики здесь не причем. Посмотрите в других программах, найдете тоже самое, чтобы далеко не ходить в 1С можете покопаться.

Ви доктор, что ви меня лечить хотите? На 10-15 тестовых позициях - "рупь-сорок-три" погрешность алгоритма, который доли посчитать должен? Ага-ага.
Это исключительно кривые руки, хотя бы потому, что в описываемом случае, после правок алгоритма эти "рупь-сорок-три" (и другие тесты) таки были правильно распределены. Насчет 1С не знаю, но,после сказанного, боюсь его еще больше.

Последний выдох ГПЖрасхождение относить все равно куда-то относить надо... или на последнюю строку или на самую большую.

ребят, вы что, с ума посходили?
1) Сумма расхождения в копейках при долевом распределении не может быть больше чем половина количества строк (при правильном подходе). Это в наихудшем случае, когда все округлении пошли в одну сторону. Когда на 10-15 строк мне говорят "рупь-сорок-три", я начинаю нервничать.
2) Это расхождение можно раскидать по копейке на каждую строку, начиная с максимально распределенных сумм.

А что, у вас иначе?

s_ustinovIzya... у вас получалось правильно автоматически распределить издержки по позициям - пропорционально сумме (есть такой стандартный функционал в распределении товарных издержек)? если нет, то проблема почти наверняка не в разработчиках.
а то обвинять легко...
Я деталей не помню - это было лет 8 назад. Функционал нестандартный, связан с алкоголем. Алгоритм был копеечный.
Доля по позиции= нормированные(Кол-во* объем штуки*процент алкоголя).
Дальше по этим долям раскидываем по позиции сумму.

s_ustinovIzya... у вас получалось правильно автоматически распределить издержки по позициям - пропорционально сумме (есть такой стандартный функционал в распределении товарных издержек)? если нет, то проблема почти наверняка не в разработчиках.
а то обвинять легко...
Я деталей не помню - это было лет 8 назад. Функционал нестандартный, связан с алкоголем. Алгоритм был копеечный.
Доля по позиции= нормированные(Кол-во* объем штуки*процент алкоголя).
Дальше по этим долям раскидываем по позиции сумму.