Цитата:
Сообщение от
vleg
Ничего личного, Insane
Как минимум первый случай (40 тыс ОС, 120 тыс операций амортизации) - не самый типичный.
Тем не менее, такая проблема изучалась пару-тройку лет назад. Проблема заключалась не столько в формировании журнала, сколько в его разноске в Главную Книгу. Модуль ОС тут не причем - для того, чтобы убедиться, достаточно сгенерить такой же по объему журнал ГК и попытаться разнести его. Core development признал ошибку работы с памятью в ядре. С тех пор, по-моему, была исправлена как ошибка ядра, так и сделана возможность формировать \ разносить амортизацию через набор журналов. Деталей уже не помню.
Проблемы были как с формированием, так и с разноской. Действительно, это ошибки памяти. Действительно, и года на прошло, как вышли фиксы. Но до этого тут полфорума исписали, ловя ошибки памяти во всех частях системы - посмотрите через поиск - там не только ОС....
Конечно, легче всего списать на "порочную практику" и т.п. - но я не напрасно привел пример не с проектной кастомизацией, а с полноценным решением, практически альтернативной системой. Здесь пахнет не специфическими требованиями конкретного проекта, а концептуальной неспособностью модуля системы справляться с расчетами.
insane - а если еще и суммовые по ОС по-разному учитываются разными моделями учета, да еще и по ним НДС должен предъявляться в тот же момент, что и НДС по самому ОС, да еще и этот самый НДС может списываться за счет разных источников, и тянуть всю эту информацию приходится с момента закупки ОС, а закупка производится через модуль склада, что вообще отдельная радость....и это еще только начало формирования снежкного кома, который в конечном итоге докатывается до налоговых регистров, а ОС попутно переоцениваются, разбираются, ремонтируются, дооцениваются.... Что делать, в "65 примеров" все на свете не впихнешь, а сертификат получать надо!
vleg, ругаться будем? конечно, знакомые мне кейсы именно такие! Зато какие про эти кейсы на Вашем сайте висят прессрелизы.......