Слов нет

[komar]

vleg, извините, но модули для демонстрации выбраны явно неудачно. Все эти примочки без переписывания практически нигде не работали. Причины -

- крайне низкая производительность (что регистры, что основные средства, что зарплата)
- корявая архитектура и отсутствие некоторой функциональности (реализовывать полноценный учет капвложений, наложенный на суммовые разницы, на еще и с учетом налогового учета, да еще и с учетом ПБУ-18, да еще и с учетом всех новшеств по НДС - это была радость! Крайне обрадовало то, что структура БД настолько хороша, что это даже и переписывать-то по-человечески нельзя. Модуль зарплаты - настолько хорош, что некоторые партнеры до сих пор предпочитают приделывать зарплату из российских систем - интерфейс реализовать проще, чем ползать с отладчиком по Вашим наворотам (вот, кстати, одно из полнофункциональных решений http://www.fincomplex.spb.ru/new/pro...rusfincomplex/ ). А налоговые регистры - как уже верно говорилось, крайне негибкое решение.)

[vleg]

Цитата:

Сообщение от komar

vleg, извините, но модули для демонстрации выбраны явно неудачно. Все эти примочки без переписывания практически нигде не работали. Причины -

- крайне низкая производительность (что регистры, что основные средства, что зарплата)
- корявая архитектура и отсутствие некоторой функциональности (реализовывать полноценный учет капвложений, наложенный на суммовые разницы, на еще и с учетом налогового учета, да еще и с учетом ПБУ-18, да еще и с учетом всех новшеств по НДС - это была радость! Крайне обрадовало то, что структура БД настолько хороша, что это даже и переписывать-то по-человечески нельзя. Модуль зарплаты - настолько хорош, что некоторые партнеры до сих пор предпочитают приделывать зарплату из российских систем - интерфейс реализовать проще, чем ползать с отладчиком по Вашим наворотам (вот, кстати, одно из полнофункциональных решений http://www.fincomplex.spb.ru/new/pro...rusfincomplex/ ). А налоговые регистры - как уже верно говорилось, крайне негибкое решение.)

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

[Insane]

Цитата:

Сообщение от vleg

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

Хммм, vleg, касательно штатной функциональности, может быть вы расскажете нам, неграмотным, как решить следующие вопросы штатными средствами:
1. Рассчитать амортизацию по ОС (три модели учета, тысяч 40 ОС). Мне кажется когда вы попробуете сформировать этот волшебный журнальчик - вопрос о быстродейтсвии модуля больше у вас возникать не будет.
2. Суммовые разницы, да с дооценкой склада, да с нюансами по НДС. Что то опять не очень верится.
и список этот можно продолжать и продолжать... И мне кажется что партнеры переписывают АХАРТА не от неграмотности, а от того, что иначе ее не внедрить...

[vleg]

Цитата:

Сообщение от Insane

Хммм, vleg, касательно штатной функциональности, может быть вы расскажете нам, неграмотным, как решить следующие вопросы штатными средствами:
1. Рассчитать амортизацию по ОС (три модели учета, тысяч 40 ОС). Мне кажется когда вы попробуете сформировать этот волшебный журнальчик - вопрос о быстродейтсвии модуля больше у вас возникать не будет.
2. Суммовые разницы, да с дооценкой склада, да с нюансами по НДС. Что то опять не очень верится.
и список этот можно продолжать и продолжать... И мне кажется что партнеры переписывают АХАРТА не от неграмотности, а от того, что иначе ее не внедрить...

Ничего личного, Insane

Как минимум первый случай (40 тыс ОС, 120 тыс операций амортизации) - не самый типичный.

Тем не менее, такая проблема изучалась пару-тройку лет назад. Проблема заключалась не столько в формировании журнала, сколько в его разноске в Главную Книгу. Модуль ОС тут не причем - для того, чтобы убедиться, достаточно сгенерить такой же по объему журнал ГК и попытаться разнести его. Core development признал ошибку работы с памятью в ядре. С тех пор, по-моему, была исправлена как ошибка ядра, так и сделана возможность формировать \ разносить амортизацию через набор журналов. Деталей уже не помню. Если обратитесь в техподдержку (можете это сделать через партнера), там вам расскажут, что надо делать.

Конечно, для авторитету полезнее все самому сделать. .

Второй случай - пишите подробнее, переправлю аналитикам, пусть копают, ежели чего не так.

[komar]

Цитата:

Сообщение от vleg

Ничего личного, Insane

Как минимум первый случай (40 тыс ОС, 120 тыс операций амортизации) - не самый типичный.

Тем не менее, такая проблема изучалась пару-тройку лет назад. Проблема заключалась не столько в формировании журнала, сколько в его разноске в Главную Книгу. Модуль ОС тут не причем - для того, чтобы убедиться, достаточно сгенерить такой же по объему журнал ГК и попытаться разнести его. Core development признал ошибку работы с памятью в ядре. С тех пор, по-моему, была исправлена как ошибка ядра, так и сделана возможность формировать \ разносить амортизацию через набор журналов. Деталей уже не помню.

Проблемы были как с формированием, так и с разноской. Действительно, это ошибки памяти. Действительно, и года на прошло, как вышли фиксы. Но до этого тут полфорума исписали, ловя ошибки памяти во всех частях системы - посмотрите через поиск - там не только ОС....
Конечно, легче всего списать на "порочную практику" и т.п. - но я не напрасно привел пример не с проектной кастомизацией, а с полноценным решением, практически альтернативной системой. Здесь пахнет не специфическими требованиями конкретного проекта, а концептуальной неспособностью модуля системы справляться с расчетами.

insane - а если еще и суммовые по ОС по-разному учитываются разными моделями учета, да еще и по ним НДС должен предъявляться в тот же момент, что и НДС по самому ОС, да еще и этот самый НДС может списываться за счет разных источников, и тянуть всю эту информацию приходится с момента закупки ОС, а закупка производится через модуль склада, что вообще отдельная радость....и это еще только начало формирования снежкного кома, который в конечном итоге докатывается до налоговых регистров, а ОС попутно переоцениваются, разбираются, ремонтируются, дооцениваются.... Что делать, в "65 примеров" все на свете не впихнешь, а сертификат получать надо!

vleg, ругаться будем? конечно, знакомые мне кейсы именно такие! Зато какие про эти кейсы на Вашем сайте висят прессрелизы.......

[ppson]

Не по тому делу на MBS наехали :-)
если вспомнить то время (рубеж 2001-2002), то собственно говоря никто и не знал сколько/какие/и в каком виде регистры должны быть. Методологии не было.
Поэтому и выпущенный продукт на то время в принципе более менее сносным.
Только с тех пор прошло 4 года, уже есть практики применения регистров (например см. постинг Тимура Слов нет ).
Только вот непонятно будет ли MBS развивать регистры или они так остануться еще одним способом вывода на экран данных из таблиц .

[mazzy]

Цитата:

Сообщение от ppson

Только вот непонятно будет ли MBS развивать регистры или...

Я бы предпочел, чтобы МБС не столько развивал эти регистры, сколько вернулся к первончальной идее налогового учета, который присутствует в международной Аксапте.

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

Но к сожалению, буржуйские налоговые проводки не работали совместно с корреспонденцией (конечно, надо бы проверить последние сервис-паки, но верится в чудо с трудом).

АНГЛИЧАНЕ РУЖЬЯ КИРПИЧОМ НЕ ЧИСТЮТ!

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

Я считаю, что надо вернуться к первоначальной идее и расширить ее. Вместо того, чтобы "рушить до основанья, а затем строить новый" модуль.

Что-то мы совсем от темы отклонились...

[vleg]

Цитата:

Сообщение от komar

Проблемы были как с формированием, так и с разноской. Действительно, это ошибки памяти. Действительно, и года на прошло, как вышли фиксы. Но до этого тут полфорума исписали, ловя ошибки памяти во всех частях системы - посмотрите через поиск - там не только ОС....
Конечно, легче всего списать на "порочную практику" и т.п. - но я не напрасно привел пример не с проектной кастомизацией, а с полноценным решением, практически альтернативной системой. Здесь пахнет не специфическими требованиями конкретного проекта, а концептуальной неспособностью модуля системы справляться с расчетами.

insane - а если еще и суммовые по ОС по-разному учитываются разными моделями учета, да еще и по ним НДС должен предъявляться в тот же момент, что и НДС по самому ОС, да еще и этот самый НДС может списываться за счет разных источников, и тянуть всю эту информацию приходится с момента закупки ОС, а закупка производится через модуль склада, что вообще отдельная радость....и это еще только начало формирования снежкного кома, который в конечном итоге докатывается до налоговых регистров, а ОС попутно переоцениваются, разбираются, ремонтируются, дооцениваются.... Что делать, в "65 примеров" все на свете не впихнешь, а сертификат получать надо!

vleg, ругаться будем? конечно, знакомые мне кейсы именно такие! Зато какие про эти кейсы на Вашем сайте висят прессрелизы.......

komar, не тратьте время на злобства и ругань.

Чтобы поставить точку по производительности ОС. В далеком прошлом (ноябрь 2002, Axapta 2.5 SP4) протестировали амортизацию на 150 тыс ОС * 3 модели учета. Для того, чтобы весь процесс уложился в заданные критерии (2 часа на все), операции пришлось разделить на множество небольших журналов по 1,5 тыс строк и выполнять с нескольких рабочих мест одновременно.Это не потребовало ре-дизайна "отвратительной архитектуры" модуля. Впоследствии производительность оптимизировали.

Возможно, полномасштабная и красивая реализация капвложений или чего-то еще и потребует большой и значительной переделки, не спорю. Пока такой острой необходимости не видно.

[komar]

Цитата:

Сообщение от vleg

Чтобы поставить точку по производительности ОС. В далеком прошлом (ноябрь 2002, Axapta 2.5 SP4) протестировали амортизацию на 150 тыс ОС * 3 модели учета. ....
Возможно, полномасштабная и красивая реализация капвложений или чего-то еще и потребует большой и значительной переделки, не спорю. Пока такой острой необходимости не видно.

А в недалеком прошлом третью версию тестировали....Без кастомизаций, на нормальном оборудовании...беда получилась. Но с тех пор уже много хотфиксов утекло, авось, и заткнули. конечно, маленькими порциями, да с 10 рабочих мест все работать будет. А с 20 рабочих мест, да по 10 штук ОС за пакет - еще лучше будет. Но это лирика все, бог с ними, с ОС.

Острой необходимости в КВ - нет? Ладно, наверное, есть необходимость тупая. Судя по ответу, разивать их не будут. Ладно....

ppson - а есть еще варианты? Сказано же - модуль получил почетную грамоту. А система получила сертификат. Их и жуйте.

P.S. вспоминается пример с одной с одного из ранних проектов по ахапте...На вопрос клиента - почему, мол, на расчитанной по всем рекомендациям поставщика конфигурации оборудования полтора пользователя вешают систему, продавальщик сказал что-то вроде - "Да что Вы! Вот посмотрите, как у меня на ноутбуке все летает....."
Видимо, нужно вместе с системой поставлять еще и свое оборудование, да еще и своих пользователей. И данные для обработки. Этакое комплексное решение....

[FDuchman]

Цитата:

Сообщение от komar

Модуль зарплаты - настолько хорош, что некоторые партнеры до сих пор предпочитают приделывать зарплату из российских систем - интерфейс реализовать проще, чем ползать с отладчиком по Вашим наворотам (вот, кстати, одно из полнофункциональных решений http://www.fincomplex.spb.ru/new/pro...rusfincomplex/ ).

Дмитрий, а это не тот ли Финкомплекс который одним человеком написан...., ты сам то его хоть смотрел?
Странно слушать от тебя сравнение ЗАРПЛАТЫ и КАДРОВ в AX и в ФИНКОМПЛЕКСЕ, которых ты совсем не знаешь......