Присматриваемся с реализации 25 главы НУ и ПБУ18 на базе решения SAP, описанного в Note 1312501 - Profit Tax Accounting Solution installation RU
Вопросы такие
1 Что значит фраза "Content of this note is being consulting solution at the part of Profit Tax Accounting for SAP All-in-One Baseline Package and carries in itself informative character. Using this note without SAP All-in-One Baseline Package may cause serious problems!!!".
Требование установки собственно add-on BP или каких-то конкретных сценариев? В http://help.sap.com/bp_bl604/BL_RU/html/index_RU_RU.htm не нашел сценария для НУ
2 для таблицы FMGLFLEXT данное решение работает?
3 наверно следствие п.1,2 - возможно ли развернуть решение для продуктивной системы ERP 6.0 EHP4 с последними уровнями SP, с активированной New GL, c FMGLFLEXT в качестве таблицы итоговых данных? Или это только исключительно для новых клиентов?

Данное решение разрабатывалось отделом SMB (среднего и малого бизнеса) SAP CIS, насколько я понимаю под руководством Михаила Шмытько. Т.к. они же занимаются и BP, то думаю скорее всего они Profit Tax Account на ГГК реализовывали на системе на которй уже был проставлен BP BaseLine (BP по базовой функциональности). Когда был на партнерском практикуме по SAP All-in-One осенью 2008 года, то Михаил на тренинге посвященном Profit Tax Account на ГГК говорил что т.к. это разработка его отдела, то он и хочет чтобы она была фишкой именно SMB решения, то есть SAP All-in-One, т.к. ресурсы большого SAP-а на эту задачу не выделялись, то и тянуть еще и на большой SAP он не хочет. Но чисто технически затронуто что то в этом решении BP Baseline или нет, не понятно - по крайней мере никто гарантии не даст что все будет работать без накатанного BP BaseLine, но с другой стороны многие же люди ставят и без Baseline, - прочитайте в разделе FI более старую тему. Насчет FMGLFLEXT думаю тоже должно работать, но может что то докуручивать больше придется - на самом деле разница между FMGLFLEXT и FAGLFLEXT только в наборе полей для сплиттинга поставляемой с ведущим регистром, добавить недостающие всегда можно через пользовательские поля и даже через добавление в стандартный набор полей (если длины в инклюде на пользовательские поля не хватает - помоему сумарная длина полей в инклюде пользовательских полей не более 255 должна быть) как один SAP эксперт тоже показывал можно делать и без проблем решению Налога на прибыль на ГГК, так что из этого можно сделать вывод что на FMGLFLEXT-е так же можно сделать Налог на прибыль, то же самое по EhP 4 можно сказать - вряд ли оно таблицы итоговых записей серьезно изменяет. А для налога на прибыль важно в первую очередь именно структура таблиц итоговых записей.

NhjirbyRfanfy,
если такие вопросы возникли, то лучше не ставить (это не в обиду сказано, просто если заниматься этим решением, то нужно понимать его идею и архитектуру полностью - ибо оно совсем не "плаг энд плэй"). А если не понимаете - то связываться не стоит. ИМХО.

NhjirbyRfanfy или методолог или архитектор или начальник по моему . По его вопросам в FM форуме и детализации проработки ответов на них, мне так показалось - реализовывать идеи наверно кто то другой будет

Извиняюсь, если ошибаюсь.

Коллеги,

Доброго дня,

После установки решения НУ на ГГК (нота 1312501) и прочтения документации возник ряд вопросов

1. Верно ли что система всегда кидает данные в не ведущий регистр (если он привязан имею ввиду NT), вне зависимости есть ли счет в иерархии или нет, если критерии не походят просто дублирует данные ведущ регистра а на налоговом объекте пусто? Соответственно нет возможности присвоит правило выбора регистра (книги) как в SL

2. Каким образом привязать операции к регистру(книге), я имею ввиду операции типа RFBU, KOAO (полный список можно посмотреть по тр GCV2)?

3. Верно ли что нет интеграции ГГК и контроллинга, все данные приходят только в том случае если есть документ финансов?

Спасибо

почти не ошиблись. Что касается замечания sas, то оно вызывает недоумение - подозреваю, редко рождаются люди с полным пониманием идеи и архитектуры PTA от SAP.

Позволю себе вставить свои пять копеек.

Поддерживаю господина sas'а. Он просто напросто не отвечает формально на Ваши вопросы, а пытается дать Вам совет относительно фразы "Присматриваемся с реализации 25 главы НУ и ПБУ18 на базе решения SAP...".
Немного разверну его утверждение. "Решение" проинсталлируется и заработает на любой таблице и вряд ли будут серьезные проблемы с использованием его без Baseline Package. Но! Только при одном условии: существенной доработке напильником знающим человеком.
И вся проблема как раз в последнем. Все можно докрутить/довинтить. Нужно только знать как.
А если Вам еще не хочется краснеть сдавая это бухгалтерам, то доработка должна быть еще более существенной...

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

Хочу поинтересоваться, а какие еще варианты рассматриваете, кроме ТПРов?

выбор стоял между решением на new gl и fi-sl. Т.е. по сути между двумя ТПР-ами. На данный момент проинсталлирован и настроен тестовый вариант на спец. регистрах.
Позволю не согласиться про незаменимость специалиста. Это уже правда флуд, но, сугубо имхо, "незаменимость" в технических областях - крайне опасный миф. В области внедрения erp тем более. Представьте - вы приходите к клиенту и говорите - вот, есть такое то решение. Только специалиста оно требует уникального - и не только на время настройки решения - это как раз хорошо - клиент получает уникальную услугу! - но и на время сопровождения. Думаю, здравомыслящий клиент выберет и третий вариант - например 1с...

Все остальное - профессионализм консультанта и высокий уровень компенсации - вполне логичные вещи, трудно с этим не согласиться.

Понятно. Тут, как мне кажется, правильная установка такая: по-умолчанию FI-SL, но если есть существенные соображения в сторону ГГК, тогда уж ГГК.


Ну скажем так: толковый консльтант Вам будет нужен отныне всегда... А его замена, в случае чего, может вылиться в большие дополнительные затраты...
Например, один клиент отдав хорошую сумму денег N за внедрение, теперь ежемесячно вынужден покупать консультанта на сумму примерно N/50. И вырваться из этого замкнутого круга уже возможности не видит, кроме как переделки всего с нуля. И это было не внутреннее внедрение, а фикспрайсовый проект с солидным подрядчиком...

То же самое можно сказать и про хорошо доработанное напильником решение по FI-SL.

Абсолютно! Хотя FI-SL - это более гибко, чем гибкая книжка. Уж простите за каламбур.

Тогда вопрос уважаемому сообществу.
В чем преимущество ТПРа по сравнению с иной реализацией (на том же FI-SL или ГГК)? И какие бы бонусы заставили бы сделать выбор в пользу альтернативного решения?

Если квалификация разработчиков иного решения и выделяемые трудозатраты на иное решение не достаточны, то оно и будет хуже ТПР, если же квалификация разработчиков налогового решения высокая и трудозатрат потратили достаточно, то тогда могут и ТПР расширить или сами сделать получше. Альтернативное решение выбирается когда Заказчика не удовлетворяет что может делать ТПР и когда Заказчик за расшиенное решение платит деньги.

Это точно!
Если делать будут крутые профессионалы и у заказчика есть на готове куча бабла, то все будет классно! Тут не поспоришь.)