ВВ123 Shuhard2 Управленческий учет весьма расплывчатое понятие :
- что кроме дебеторки/кредиторки/прибылей убытков/движения денежных средств и главной книги хотите видеть ?
- контрагенты,холдинги,договора,множественность юр.лиц ?
- накладные расходы <-> себестоимость
- субконто<>аналитики

Цели:
1.ведение 3 отдельных Юр лиц с последующей консолидацией
2. Снижение себестоимости разработки программных продуктов
3. прозрачный финансовый учет

Аналитики по статьям расходов: вид деятельности, ЦФО, договор, Программный продукт, контрагент. Косвенные расходы будем распределять пропорционально прямым.

Вести 3 отдельных юрлиц Вы сможете, а вот последующую консолидацию врядли.
А что такое прозрачный финансовый учет я не понял ?

LuciusИ тем не менее, вопрос о SAP BO.

Абсолютно аналогичная ситуация, правда решение все еще не принято.
Хочу на SAP сделать управленческий и товарный учеты, для упаравляющей компании, 2-ух складов и магазина.

Может быть кто нибудь имеет опыт внедрения SAP BO в торговле

Интересует объединенный учет для 4-х подразделений с 4-мя же различными базами и консолидацией всех данных в центральной БД.
Поделитесь, пожалуйста, опытом.

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

Shuhard AnS1 Если нужна функциональность SBO, можно найти ГОРАЗДО дешевле.
Гораздо означает сколько ?
Можно найти означает какие ?
ИМХО. По мне 1С8 лучше и дешевле СБО адназначно.
Если уж очень хочется Сапа, лучше тады mySap брать.

Сисой BB123Смотрела много систем/команд/решений. Выбор уже сделан в пользу SBO. Считаете ошибкой?. Но так же ругают и все остальное 1С 8 - много скрытых затрат и косяков, Навижен - да у нас нет хороших внедренцев, извините. Мне и систему не смогли толком показать. Галактика - наеверное хорошо, но не смогли даже простенький контрольный пример реализовать Еще понравился Инталев. Наши проблемы решает. В финал у нас вышли три системы (исходя из нашего бюджета) : Инталев, SBO, и Галактика. Сейчас начинаем с Нового года внедрять. Вопрос прежний. Кто-нибудь есть здесь кто внедрял/внедрил/работает на SBO? Поделитесь своим опытом, плиз!

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

Истина. Подписываюсь.

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

iBolt рекомендованное средство, но Ваш партнер может написать в "лоб", через SDK DI


Что такое маркетинговые документы, я не понял. Просветите.
Правильнее использовать SDK. Во сколько обойдется репликация на iBolt.

Lucius
Меня проигнорировали в SAP CIS, вот после этого я и пошел искать правды к ВАМ

Мне каааца Сап Цису такие небольшие по бюджету (30 - 100 тыс. евро) проекты не очень интересны. Мне так каааца. :)

Shuhard steplton
Мне каааца Сап Цису такие небольшие по бюджету (30 - 100 тыс. евро) проекты не очень интересны. Мне так каааца. :)
SAP CIS так не кажется , МСБ за 2005 г. дал 10% выручки
Это во всем мире или в СНГ. Ссылочку мона, откуда такие цифирки.

Респликацию документов можно сделать с помощью SDK.
Но сразу же подробно распишите сроки и стоимость.
Чтобы потом не удивляться. :)

Принцип примерно такой:

В каждой дочке -
Sap Business One
MS SQL Server
Аддон с выгрузкой данных в файл (напрмер в XML формате).

В головном офисе -
Sap Business One
MS SQL Server
Аддон с подгрузкой данных из филиалов.

Только вести данные по нескольким фирмам в голове в одной базе ?

Lucius stepltonТолько вести данные по нескольким фирмам в голове в одной базе ?
Да нет, не вести, а учитывать.
Менеджер по закупкам должен знать, что у него на скадах, что продалось в магазине (причем с оперативностью не ниже получаса). Кроме того, склад отгрузил, магазин должен принимать, обмен я предпочитаю делать через центр (товар в пути)

Консолидация проводок по управленческому учету - как я понял функционал страндартный.

Подскажите, пожалуйста, а есть в SBO ограничение на количество аналитик в проводках (вот в 1С всего 3 субконто) в галактике, навижн - неограничено, (кажтеся 6 по умолчанию).
Мне 4 нужно по управленческому плану счетов.

>Да нет, не вести, а учитывать.
Это одно и тоже.

Получасовая консолидация - это практически он-лайн. :))
Т.е. два раза в час сотрудник должен по почте отправлять данные в голову.
А в голове (сотрудник или автомат) должен загружать данные.


По аналитике в проводках.
Если я Вас правильно понял в СБО в проводке есть след. аналитики (стандартные)
1. Номер счета/БП
2. Проект
3. Правила распределения

Также можно добавить в проводку так наз. пользовательские поля.
Их количество в принципе тоже неграничено.
Только придется дописывать функционал при проведении с учетом дополнительной аналитики.

Shuhard[quot stepltonДа нет, не вести, а учитывать.
Это одно и тоже.
Т.е. два раза в час сотрудник должен по почте отправлять данные в голову.
А в голове (сотрудник или автомат) должен загружать данные.

1 Вести и учитывать не есть одно и тоже
2 Жидковатый адон выходит , сжать и отправить файлик по SMTP не проблема[/quot]

Про 1 поподробнее будьте любезны. А то написали как отрезали.

Про 2 - В любом случае это входит в стоимость. А про написание самой выгрузки (документов) забыли ?

Lucius1 Вести и учитывать не есть одно и тоже
Вести, это когда в 2-х БД могут создаваться уникальные записи, и их нужно "взаимореплицировать" (Обычно решается разведением по ключу учетных записей). Я хочу, чтобы уникальные записи по одному бизнес процессу создавались только в одном месте, а в Центр передавались без возможности изменить или добавить. (отсутсвие документов в Центре будет ограничением для реализации DrillDown при надстройке аналитической системы)

Я Вас немного непонял. Что значит вот этот момент - Обычно решается разведением по ключу учетных записей. Пожалуйста поподробнее.
Просто действительно интересно чем ведение отличается от учета.

LuciusПробую еще раз
В терминах, которыми я оперирую:
Вести данные - это создавать учетные записи (например приход на склад).
Если эти приходы создавать только в БД склада, а в центральную БД только собирать как факт, без возможности изменения - это учитывыать факты.

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

Вроде понял Вашу терминологию. Списибо за объяснение.

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

Есть жизненное правило - где информация создается, там должна и изменяться. Согласитесь было бы странно если бы в ЦО правили доки филиалов.

Распределение дапазов учетных номеров в СБО есть в настройках.