Какой механизм действия свойства? В каком случае сабж возвратит True? Для того, кто решит ответить - "В том случае, когда Entity - ОС", вопрос звучит так - Как Акцент определяет, что объект учета - ОС?
Какой механизм действия свойства? В каком случае сабж возвратит True? Для того, кто решит ответить - "В том случае, когда Entity - ОС", вопрос звучит так - Как Акцент определяет, что объект учета - ОС?
Смотрим справку... А еще - пытаемся создать объект учета и смотрим, что же Акцент предлагает...
Смотрим справку... А еще - пытаемся создать объект учета и смотрим, что же Акцент предлагает...
В справке по IsAsset принцип действия не описан.
Я правильно понимаю, что при запросе свойства проверяется тип ОУ и если его значение 1006-1013, Либо 1019 то св-во возвращает true?
Что касается справки по Entity.Type, то там ошибка - не указан тип "Ценные бумаги", который 1018 и не является ОС. А под значением 1018 указан тип МНМА, значение которого на самом деле 1019.
Добавлено: Чт Июн 07, 2012 9:12 am Заголовок сообщения:
Принцип не описан. Но описаны собственно объекты учета, при попытке создать ОУ в Акценте, основные вынесены в отдельный пункт.
А что мешает просто создать десяток ОУ и проверить, одинаково ли Акцент думает в разных случаях?
Добавлено: Чт Июн 07, 2012 10:39 am Заголовок сообщения:
kris писал(а):
Принцип не описан. Но описаны собственно объекты учета, при попытке создать ОУ в Акценте, основные вынесены в отдельный пункт.
А что мешает просто создать десяток ОУ и проверить, одинаково ли Акцент думает в разных случаях?
Эмпирические показатели недостаточно надежны, поскольку каждый из них можно рассматривать только как частный случай. Ну да ладно. Похоже работает так как я написал. А вообще, я спросил это что бы уточнить, связано ли как-то свойство IsAsset с объектом Asset. Значит никак не связано, и смотрит оно только на значение Entity.Type.
Добавлено: Пт Июн 08, 2012 10:58 am Заголовок сообщения:
Детально, действительно не описано. Впрочем, подробное описание для, например, Op.Done тоже нигде не приводится. А оно вычисляется аналогичным образом, т.к. в базе DOCUMENTS.DOC_DONE может приобретать несколько больше значений, чем 2. Просто надо немного "додумать" и поскольку перечень типов основных средств достаточно невелик и врядли будет расширен когда-нибуть... Не вижу здесь никаких особых проблем с "эмпирическим методом", т.к. перечень опытов конечен и может быть легко предворен в жизнь
В корне не согласен А что, если свойство запрограммировано возвращать true, если имя объекта, к примеру "Наш_экскаватор"? Мы ведь не можем узнать о подобных вещах эмпирическим путем? И вообще зачем искать черную кошку в темной комнате?
~~~~~~~
Вопрос на эту же тему. Может я что-то конечно пропустил в документации, но как через объектную модель выйти на поле AST_ENABLED из таблицы ENT_ASSETS (Начислять ли амортизацию на данное основное средство)?
Вопрос на эту же тему. Может я что-то конечно пропустил в документации, но как через объектную модель выйти на поле AST_ENABLED из таблицы ENT_ASSETS (Начислять ли амортизацию на данное основное средство)?
Видимо, никак. Более того - в 7.0 и 7.4 я и в интерфейсе тоже не вижу этой галочки. А если верить структуре таблицы и хранимке ap_asset_save, то оно просто всегда = 1:
Код:
if exists(select * from ENT_ASSETS where ENT_ID=@id)
-- update
update ENT_ASSETS set AST_IN_DATE=@indate, AST_IN_ACT_NO=@inact, AST_IN_ACT_DATE=@inactdate,
AST_MANUFACT=@manuf, AST_MANUF_DATE=@manufdate,AST_PASSPORT=@passp, AST_REG_NO=@regno,
AST_DEPREC_CODE=@depcode,AST_DEPREC_PERCENT=@depercent,AST_OUT_DATE=@outdate,
AST_OUT_ACT_NO=@outact,AST_OUT_ACT_DATE=@outactdate,AST_USEFUL_LIFE=@life,
AST_OUT_REASON=@reason
where ENT_ID=@id
else
-- insert
insert into ENT_ASSETS
(ENT_ID,AST_ENABLED,AST_IN_DATE, AST_IN_ACT_NO,AST_IN_ACT_DATE,AST_MANUFACT,AST_MANUF_DATE,
AST_PASSPORT,AST_REG_NO,AST_DEPREC_CODE,AST_DEPREC_PERCENT,AST_OUT_DATE,AST_OUT_ACT_NO,
AST_OUT_ACT_DATE,AST_USEFUL_LIFE,AST_OUT_REASON)
values
(@id,1,@indate,@inact,@inactdate,@manuf,@manufdate,@passp,@regno,@depcode,@depercent,
@outdate,@outact,@outactdate,@life,@reason)
Видать, это поле рудиментарно, как и CRC_ID, J_CSUM и J_CESUM в JOURNAL в 7.4...
...хранимке ap_asset_save, то оно просто всегда = 1
а ap_asset_load, его даже не загружает.
kris писал(а):
Видать, это поле рудиментарно
И в Стандарте теперь используется вместо него параметр ОС "Не считать амортизацию". Интересно, чем перестало устраивать свойство объекта. Или оно никогда и не использовалось?
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах