Холдинг как одна или несколько компаний в Аксапте?

[Михаил Андреев]

2 Ariman

Без детального анализа бизнес требований дать нужный рецепт практически невозможно.
Можно несколько юрлиц сделать в одной компании Аксапты (доработав первичку и отчёты), можно, наоборот, одно юрлицо "размазать" по нескольким компаниям Аксапты (например, те же филиалы).
Заранее сказать, что это будет лучше всего, просто нереально. За всё приходится платить, это выбор компромисса.

Вот здесь обсуждали немного похожую проблему:
Как сделать управленческий и финансовый учет?

[Михаил Андреев]

Цитата:

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

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

Хм. Что за информацией они обменивались, которая потребовала большого объёма программирования?

Цитата:

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

а в данном случае, если я правильно понял топикстартера, мы имеем дело не с филиалами, а фактически с разными направлениями деятельности одной компании. Первое направление продает лампочки производителя Х, второе - такие же лампочки производителя Y. Их надо разносить по разным компаниям?

Честно говоря, я тоже не очень понял Потому "лечить по телефону" и не пытаюсь - надо изучать проблему в деталях, здесь каждая мелочь важна.

[Vals]

Цитата:

Интеркомпании заточены именно под цепочки, которых у нас нет.

Интеркомпани это лишь небольшой кусочек функциональности, которая, начиная с четвёртой версии называется AIF (Application integration framework), добавлены некоторые вкусные функции при работе с несколькими компаниями и т.д. Обращаю внимание, что Интеркомпани работает и в одной компании
Здесь некоторая инфа по AIF http://www.amand.ru/modules/wordpress/archives/74

[Zodiak]

Цитата:

Сообщение от Михаил Андреев

Хм. Что за информацией они обменивались, которая потребовала большого объёма программирования?Честно говоря, я тоже не очень понял Потому "лечить по телефону" и не пытаюсь - надо изучать проблему в деталях, здесь каждая мелочь важна.

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

[Михаил Андреев]

Цитата:

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

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

Хм. А другие решения не рассматривались? Например, навскидку, объединить справочники номенклатуры и строки заказов (не факт, что заголовки надо объединять), и прицепить к ним статусы (ну, или расширить существующие)?
М-да. Ещё раз убеждаюсь, что одна мелкая ошибка на самом раннем этапе может стоить на порядок дороже, чем большая на самом последнем...

[Zodiak]

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

[mit]

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

1. добавление (или изменение) дополнительной финансовой аналитики - юр-лицо.
2. добавление дополнительной складской аналитики - юр-лицо.
3. добавление доп. справочника юрлиц с названиями, кодами, адресами…
4. настройка (и дальнейший доп. контроль чтобы всегда заполнялись в справочниках для новых позиций) счетов плана счетов, клиентов, поставщиков, номенклатуры чтобы аналитика обязательно была заполнена
5. доработка финансовой отчетности (но это и без юрлиц требуется)
6. написали функционал, который позволяет «прописать» (и администрировать актуальность прописанных) доступных пользователю группу юр-лиц
7. в 3.0 rls настроили на все таблицы по аналитике , но работает коряво, думаю, что из-за того, что аналитика реализована через массив. Корявость в том, что криво срабатывал фильтр при наложении условий на другие финансовые аналитики. Уж не помню точно, но толи не учитывал фильтр и показывал все, толи все записи прятались. В основном же, rls работает нормально и администрируется просто.
8. при включенном rls, если бухгалтер при заведении проводки не указал юрлицо, ушел со строки, или закрыл журнал – проводка спряталась, журнал не разнесется.
9. доработка складской отчетности (для финансистов)
10. доработка стандартных форм отчетов с авто нумерацией и названиями компаний адресом
11. отчетность консолидации (а думаете не нужно вычищать интеркомпани продажи?)
12. удаление данных компании … хлопотно, но сделали всего один раз (но зато сразу грохнули десяток J)
13. RecId наверное уже не проблема, а в 3.0 с замиранием сердца мониторили
14. Смена названия компании наверное частный случай с перепродажей. Но так как механизм искусственный, теряется сквозная аналитика. Т.е. товар прошел через финансовый цикл продажи, а через физический нет. аналитика складская вся поехала. Инвентаризация была веселой.
15. Возможно что то еще, но основное кажется перечислил.

постоянно:

1. дополнительные операции по перепродаже между юрлицами, соответственно с ценообразованием
2. смешанные справочники. Даже не знаю, называть ли это минусом. Ну допустим если торгуем углем, то всего там сортов – несколько десятков можно придумать. Поиск номенклатуры происходит при помощи глаза по экрану и пальца по мышиному колесу с прокруткой. А если запчастями, то несколько десятков тысяч, поиск как ни крути через нормальный (или навороченный) механизм поиска. Если в уголь попадет какая ни будь акция или вексель – могут быть всякие вопросы, или визг, что мол это у меня тут такое, уберите! Если в запчасти – никто и не заметит. На качество учета и сервиса не влияет, но может нервировать нервных.

плюсы:

1. заведение юрлица – не более пяти минут. заполнение одной строки в справочнике юрлиц. Соответственно никакое тестирование не требуется.
2. удобство использования и администрирования, если не требуется разделять пользователей по юрлицам, и все работают в одном информационном пространстве
3. удобно торговать, (если все равно чьё продаём)
4. удобно планировать производство
5. расходы начисляются и размазаваются по себестоимости – в лёт (все проводки меченые)
6. любой отчет хоть по компании, хоть по трем, хоть по всем

дополнительная реализация холдинга в компаниях, около 15 шт. (причина - разные планы счетов, разные валюты учета, разные цели учета, плюс непреодолимые минусы одной компании), минусы:

1. настройка юрлица 1-2 недели. каждый раз – как настройка системы. Почти с нуля. всех этих разносок, номерных серий… (если компании по настройкам очень разные – перенос потаблично, использовался джобик while select… changeCompany()… если идентичные – проще скопировать компанию целиком, почитстить проводки и немного оттюнинговать)
2. при добавлении справочника в виртуальную компанию (например, чтобы курсы валют иметь общие для всех компаний) – перезапуск системы обязателен.
3. Возможно придется написать (код) переноса между компанией проводок
4. консолидация данных (настройка маппинга)

плюсы:

1. настройка доступа – системная реализация
2. начать новый год с чистого листа намного проще.
3. Делать архивы через компании – тоже можно использовать базовый функционал копирования данных компании.
4. проще кодировать разный функционал для разных компаний. Хотя в пятерку засунули много чего, а в своё время и документооборот писали, и оповещения почтой и правила всякие для проводок – это в одну компанию, то в другую
5. проще с филиалами и по конфиденциальности, и по разбору «косяков»
6. мощный инструмент по сводному планированию и по консолидации финансовой информации
7. удаляется компания – просто как одна запись в справочнике компаний. Только немного дольше

напрашивается вывод: если у пользователей не пересекается ответственность за однородные данные, пользователи постоянно работают с разными юрлицами холдинга, то лучше работать в одной компании. Если раздельный баланс, раздельные продажи, раздельные справочники, то проще в разных, и потом консолидировать.
Данные, по крайней мере основные, достаточно просто перекинуть как из двух компаний в одну, так и разделить по какому то признаку по разным компаниям. Если исходить из этого предположения, то на мой взгляд, лучше начинать работу в разных компаниях

[mit]

еще вспомнил про закрытие периода. раздельно закрыть период по аналитике юрлицо в одной компании невозможно. эта функция доступна только при использовании разных компаний