Сквозные таблицы для нескольких фирм

[SDauren]

Всем, привет!

Помогите с проблемой. Есть база, NAV 4.0 SP3 Navision Attain, на ней несколько фирм.
В каждой фирме есть таблица Item, и есть движение по товаром. Необходимо сделать таблицу item сквозной, т.е. общей для всех фирм.
Как такое можно сделать с меньшими затратами человеко часов?

Всем заранее огромное спасибо.

[Dzemon]

Можно задать свойство таблицы DataPerCompany = No, но это НАСТОЯТЕЛЬНО НЕ РЕКОМЕНДУЕТСЯ, т.к. механизм расчета себестоимости проставляет в этой таблице свою галку.

[rmv]

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

[SDauren]

Спасибо, за ответ. А можно ли по подробнее о механизме, как и где он меняет это свойство таблицы?

[Dzemon]

Microsoft Dynamics Blogs
Тут поищите, статья была.

[DA_NEAL]

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

[SDauren]

Большое спасибо всем за советы, попробую синхронизировать эту таблицу.

[RedFox]

Цитата:

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

Большое спасибо всем за советы, попробую синхронизировать эту таблицу.

Только не удаляйте данные из таблицы Товар в сопроводительных фирмах, потому что потеряете "связанные записи"!

[Yermek]

2 Dzemon К сведению если вы говорите об этой статье http://dynamicsuser.net/blogs/alexchow/arc...ersion-5-0.aspx
то там речь идет про 5-ю версию и нововведенные там поля "Cost is Adjusted", "Cost is Posted to G/L". Хотя многие советует не использовать это св-во и для более ранних версий. Интуитивно как-то это понятно, только вот нету четкого обоснование почему не следует так делать...

Интересно, а "осторожность обращения" со свойством datapercompany для ведения общих справочников в нескольких фирмах свойственно только справочнику товаров? Что насчет других справочников, например ОС, Вендоров, Клиентов?
И такой еще момент, проблемы возникают если хотя бы в двух фирмах (в одной базе) есть уже заполненные справочники и сделаны какие-то учтенные операции по товарам. Тогда изменить это св-во datapercompany на "горячем ходу" очень не удобно. Но если бы движений по товарам не было бы т.е. фирмы были бы "чистыми" ещё без каких-либо учтенных операций, тогда это проблемка отпадает. Т.е. если ещё на стадии проектированияи подготовки базы предусмотреть необходимость создания "сквозных таблиц" справочников, то насколько все будет гладко в дальнейшем?

[Alex Che]

Цитата:

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

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

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

[Arshak]

Делали общими таблицы на одном проекте. клиенты, поставщики, и все насроечные таблицы работают нормально. с товаром создали таблицу, типа как рекомендует Da_NEAl, из нее сделали функцию переноса во все фирмы через changecompany. удаление товаров запретили в приципе (см. сообщение Red Fox). ненужные товары можно блокировать в нужных фирмах.
да и такое можно делать только на стадии проектирования базы, пока нет операций.

[SDauren]

А если база находится на стадии разработки, то можно ли сделать таблицу item общей для нескольких фирм.
Или это очень не желательно и могут возникнуть большие проблемы в дальнейшем?

[rudnev]

Цитата:

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

А если база находится на стадии разработки, то можно ли сделать таблицу item общей для нескольких фирм.
Или это очень не желательно и могут возникнуть большие проблемы в дальнейшем?

с себестоимостью будут очень большие проблемы, особенно если в разных компаниях разные LCY.
есть конечно выход - обязательное использование SKU и расчет себестоимости "товар-склад-вариант", но даже в єтом варианте при некоторых условиях некорректно отрабатывает коррекция

[Arshak]

не могут а будут точно!

[Mitjay]

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

Мы реализовали это следующим образом:
1) Открыли все учетные таблицы, справочники, кроме таблиц с настройками; 2) Разделение по фирмам и на упр/бух учет - через глобальные измерения; 3) У товаров метод расчета себестоимости по средней и в разрезе склад,товар, вариант; склады по фирмам; применение товарных операций с фильтром по глобальным измерениям.

Подскажите, где могут проблемы возникнуть.

[Fordewind]

Цитата:

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

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

Мы реализовали это следующим образом:
1) Открыли все учетные таблицы, справочники, кроме таблиц с настройками; 2) Разделение по фирмам и на упр/бух учет - через глобальные измерения; 3) У товаров метод расчета себестоимости по средней и в разрезе склад,товар, вариант; склады по фирмам; применение товарных операций с фильтром по глобальным измерениям.

Подскажите, где могут проблемы возникнуть.

Кстати, а чем ваше решение по идеологии сильно отличается от дистрибуторских центров?

[Mitjay]

Цитата:

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

Навскидку что еще нужно допилить:
1. Применение клиентских и поставщических операций с фильтром по фирме.
2. Коррекция курсовых в разрезе фирмы.
...

Да, все это делали...

Цитата:

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

Кстати, а чем ваше решение по идеологии сильно отличается от дистрибуторских центров?

В принципе ни чем не отличается, что так куча доработок, что этак.

[rmv]

Навскидку что еще нужно допилить:
1. Применение клиентских и поставщических операций с фильтром по фирме.
2. Коррекция курсовых в разрезе фирмы.
3. Закрытие периода обязательно в разрезе фирмы.
4. Резервирование и партионный/серийный учет в разрезе фирмы уже сделали?
5. Если не разделили склады по фирмам - могут проблемы со сложным складом (в Warehouse Entry нет измерений).
6. Заборы : запрет перемещений с фирмы на фирму (наверно нужно делать через продажу и покупку, либо через списание и оприходование); фин. учет - запрет всех операций, где в дебете одна фирма, в кредите другая (ибо нарушается принцип двойной записи).
7. Разные приятные мелочи вроде распределения издержек, контроля кредитного лимита, серьезное переписывание кода при смене глобального измерения в заголовках документов.

[el']

А как думаете, если при расшаренной таблице товаров перед запуском коррекции у всех товаров (в карточке)программно снимать галку "Себестоимость скорректирована". По идее в таком случае проблема с коррекцией решается.

[el']

Потестили. Решается.
Остается доработка отработки триггеров в расшаренной таблице по нерасшаренным таблицам по всем фирмам.