DocuValue свойство SaveDataPerCompany = "No" ???

[veps]

Почему для таблицы DocuValue (Стоимость по документу) свойство SaveDataPerCompany установлено в значение "No" ???

[kashperuk]

Попробуем зайти с другой стороны. А почему бы и нет?
Такой вопрос будет более уместным для таблицы DocuRef, по-моему. Но там тоже есть ответ - потому что ссылка идет по 3 полям - Компания/Таблица/Запись (RefCompanyId/RefTableId/RefRecId)

[glibs]

Почему, почему...

Вы про виртуальные компании что-то слышали? Как работает документооборот представляете?

А теперь представьте себе следующее. Есть две компании А и Б. Предположим, что у них общий план счетов (в виртуальной компании, имеется в виду) и свои справочники клиентов. Документы нужно цеплять и туда и сюда. Причем документы на плане счетов должны быть общими, а на клиентах — нет.

Как вы предложите решать эту дилему?

[kashperuk]

Off-Topic:

Неужели действительно кто-то перевел метку таблицы DocuValue как "Стоимость по документу"??

[glibs]

Off-Topic на Off-Topic:

Микрософт жжет. Как в сказке про Змея Горыныча, когда у него головы спорили друг с другом.

[Vals]

Цитата:

Неужели действительно кто-то перевел метку таблицы DocuValue как "Стоимость по документу"??

А что далеко ходить, если в форме "внешние коды" метка "Value" переведена как "себестоимость".
Правильно она была переведена только в Axapta 2.5 какого-то сервис пака.

[gaenar]

Ага. Только вот есть один глюк - если поставить в примере глибса на табличке LedgerTable св-во SaveDataPerCompany в No, получим удивительный результат! Все документы цепляются, но нихрена нельзя просмотреть.

Уважаемый глибс, вы пробовали сами свой пример?
Если да, у Вас тот же результат?
(AX 3.0 SP4)

[kashperuk]

Цитата:

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

Ага. Только вот есть один глюк - если поставить в примере глибса на табличке LedgerTable св-во SaveDataPerCompany в No, получим удивительный результат! Все документы цепляются, но нихрена нельзя просмотреть.

Уважаемый глибс, вы пробовали сами свой пример?
Если да, у Вас тот же результат?
(AX 3.0 SP4)

Нуу. Погодите. Тут ничьей вины, кроме вашей, быть не может.
Что ж Вы меняете это свойство ПОСЛЕ добавления записей?
Если уж так сделали, то очень просто все поправить - просто измените код компании (RefCompanyId) для всех строк таблицы DocuRef, у которых RefTableId == tableNum(LedgerTable). Установите ему значение DAT

Тогда записи будут отображаться.

[glibs]

Цитата:

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

...
Если уж так сделали, то очень просто все поправить - просто измените код компании (RefCompanyId) для всех строк таблицы DocuRef, у которых RefTableId == tableNum(LedgerTable). Установите ему значение DAT
...

Есть шанс нарваться на конфликт RecId в LedgerTable в компании DAT. Вероятность не высока, но существует.

Но это будет последствием изменения свойства на уже заполненной таблице, а не обновления ссылок.

[gaenar]

Цитата:

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

Нуу. Погодите. Тут ничьей вины, кроме вашей, быть не может.
Что ж Вы меняете это свойство ПОСЛЕ добавления записей?
Если уж так сделали, то очень просто все поправить - просто измените код компании (RefCompanyId) для всех строк таблицы DocuRef, у которых RefTableId == tableNum(LedgerTable). Установите ему значение DAT

Тогда записи будут отображаться.

Причём здесь "моя вина"? Я что, написал что я установил это свойство уже на имеющихся данных? Читайте внимательнее, уважаемый Иван.
Про проблему - читайте выше. На новых записях привязка не работает.
Если проапдейтить RefCompanyId до DAT, то их становится видно.
Но для новых DocuRef она всё равно пихает в RefCompanyId код ТЕКУЩЕЙ компании.
И поэтому они не видны.

[glibs]

Цитата:

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

...
в примере глибса на табличке LedgerTable св-во SaveDataPerCompany в No, получим удивительный результат! Все документы цепляются, но нихрена нельзя просмотреть.

Уважаемый глибс, вы пробовали сами свой пример?
...

А где я предлагал "на табличке LedgerTable св-во SaveDataPerCompany в No"?

Вы точно различаете "св-во SaveDataPerCompany" и Администрирование\Настройки\Виртуальные компании?

[glibs]

Цитата:

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

Ага. Только вот есть один глюк - если поставить в примере глибса на табличке LedgerTable св-во SaveDataPerCompany в No, получим удивительный результат! Все документы цепляются, но нихрена нельзя просмотреть.

Уважаемый глибс, вы пробовали сами свой пример?
Если да, у Вас тот же результат?
(AX 3.0 SP4)

Насколько я понимаю, речь идет о баге (Микрософт его признал), суть которого в том, что в общую (не виртуальную) таблицу документ можно добавить только из компании DAT? При добавлении документа из другой компании он не добавляется.

В 3.0 сп3 еще воспроизводится, В 3.0 сп6 и 4.0 сп2 работает как надо. Когда точно исправили не помню, но можно поискать в Гугле (английскими буковками). Информация проскакивала.

[gaenar]

Цитата:

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

В 3.0 сп3 еще воспроизводится, В 3.0 сп6 и 4.0 сп2 работает как надо. Когда точно исправили не помню, но можно поискать в Гугле (английскими буковками). Информация проскакивала.

Спасибо, посмотрю в версиях посвежее, как там сделано.

[kashperuk]

Если следовать Best Practice, то в компании DAT данных быть не должно. То есть если конфликтов RecId не возникнет на этапе установки свойства SaveDataPerCompany, то и дальше, с DocuRef их вроде как уже не должно быть.

[glibs]

Цитата:

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

...
Если следовать Best Practice
...

А ссылочки нет, случайно? А то я сам всем советую...

По вопросу. После "обобщения" плана счетов у него грохнется DataAreaId. Если запись уже была создана, то RecId выделялось в рамках некой компании. После "обобщения" RecId будет выделяться из DAT. Гарантии того, что в план счетов больше не будут добавляться записи нет. Ссылки на план счетов по RecId есть (те же итоговые счета, кстати, их тоже тогда нужно "обобщать").

[kashperuk]

Цитата:

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

А ссылочки нет, случайно? А то я сам всем советую...

Неа, ссылочки нету. Но я точно помню, что где-то там это написано. (в ВР для 3ки)

[glibs]

Чет в BPHB по сочетанию букв DAT ничего вообще не находится .

В лицензионном соглашении тоже.

А вообще можно, по-моему. Удалить ее нельзя. Чистить сложнее. В общем, не желательно, но можно. Это если с технической т.з.

[kashperuk]

Понятно что можно. Но не стоит

Там была фраза типа "компанию dat следует использовать только для административных целей. Перед заливкой данных создайте другую компанию"

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

[Vals]

Цитата:

Там была фраза типа "компанию dat следует использовать только для административных целей. Перед заливкой данных создайте другую компанию"

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

[veps]

Цитата:

Цитата:

Есть две компании А и Б. Предположим, что у них общий план счетов (в виртуальной компании, имеется в виду) и свои справочники клиентов. Документы нужно цеплять и туда и сюда. Причем документы на плане счетов должны быть общими, а на клиентах — нет.

Как вы предложите решать эту дилему?

Ясно.

для плана счетов, поле RefCompanyId таблицы DocuRef равно значению curExt() (class\smmDocuments\getDataAreaId) , несмотря на то что план счетов включен в виртуальную компанию, если поменять значение RefCompanyId на виртуальную компанию то всё четко.

спасибо что написали ответ на второй вопрос, что присвоение значения RecId для таблицы с SaveDataPerCompany = "No" уникально для компании DAT