Заблокировать финансовую аналитику?

[sukhanchik]

Цитата:

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

Axapta 4.0 sp2
Возможно ли в стандартном функционале закрытие аналитик таким образом, чтобы ее нельзя было выбрать ни в заказе, ни в закупке, ни где либо еще.
Знаю, можно удалить ее, но это не подходит.
Можно также закрыть ее для разноски, что тоже не устраивает.

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

Для использования всего этого поставьте в параметрах главной книги параметр "Активировать наборы" (закладка Главная книга) в значение "При обновлении и разноске"

[Raven Melancholic]

Цитата:

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

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

Выбрать-то все равно можно. Например:

• переключившись на закладку "Все";
• введя значение вручную;
• скопировав из буфера обмена.

А вот разнести (или сохранить - зависит от настроек модуля) уже нельзя.

Цитата:

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

Для настройки RLS нужно знать исчерпывающий список мест, где аналитику не нужно видеть

Ну зачем-же? Для исключения из лукапа - достаточно RLS на таблицу аналитик и в паре мест, где заполнение временной таблицы производится при помощи select чуть-чуть поправить код, чтобы select использовал RLS. А для запрета ввода руками - настраиваем наборы аналитик, ну или по старому - настраиваем план счетов, но тогда запрет будет только для разноски, а не для сохранения..

[sukhanchik]

Цитата:

Сообщение от Raven Melancholic

Выбрать-то все равно можно. Например:

• переключившись на закладку "Все";
• введя значение вручную;
• скопировав из буфера обмена.

А вот разнести (или сохранить - зависит от настроек модуля) уже нельзя.

А вот тут Вы ошибаетесь.
Все зависит от параметра "Активировать наборы".

В частности, в заказах на продажу проверка стоит на методе SalesTable.validateWrite()
Т.е. заказ не сохранится, если значение не будет являться разрешенным. Хотя само поле заполнить конечно можно

[Raven Melancholic]

Цитата:

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

А вот тут Вы ошибаетесь.
Все зависит от параметра "Активировать наборы".

Так я же и говорю, что место проверки запрета (разноска или разноска и сохранение):

Цитата:

зависит от настроек модуля

В том же validateWrite третий параметр метода проверки передается true

[sukhanchik]

Цитата:

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

Хорошо. Почему бы "топикстартеру" это значение просто временно не переименовать, например в "Не используется". Потом вернёт обратно.

(на правах предположения) Потому что:
1. Пользователь может "не заметить" (хотя это бред конечно - но тем не менее)
2. Возможно, что (только если есть свои модификации) что-то сделано так, что не отреагирует на переименование аналитики

Цитата:

Сообщение от Raven Melancholic

Так я же и говорю, что место проверки запрета (разноска или разноска и сохранение):

В том же validateWrite третий параметр метода проверки передается true

Он говорит о том, что осуществлять проверку при сохранении и разноски - в зависимости от параметра.
Если бы передавался false - то проверка осуществлялась бы только при сохранении (но не при разноске) без учета параметра.

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

[Bober]

Цитата:

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

(на правах предположения)

propeller'а в студию !

[Raven Melancholic]

Цитата:

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

Он говорит о том, что осуществлять проверку при сохранении и разноски - в зависимости от параметра.
Если бы передавался false - то проверка осуществлялась бы только при сохранении (но не при разноске) без учета параметра.

Я даже засомневался в том, что знаю и чем пользуюсь
Пришлось лезть в код метода checkDimension:

    if (!this.useValidation() ||
        (LedgerParameters::find().DimensionSetActive == DimensionSetActive::AtPosting && _checkWriteValidation))
    {
        return true;
    }

То есть, третий параметр (checkWriteValidation) говорит о том, что в данный момент нужна проверка именно сохранения. И если это так, а в параметрах модуля выбрано значение AtPosting, то проверки не осуществляется. А то что в параметрах не стоит None, проверяется в методе useValidation
То есть метода

Цитата:

только при сохранении (но не при разноске)

просто не существует

[sukhanchik]

Цитата:

Сообщение от Raven Melancholic

То есть метода
только при сохранении (но не при разноске)
просто не существует

Его не существует (и режима такого не существует).
Но:
1. Если в параметрах модуля выбрано не AtPosting (При разноске), а AtUpdateAndPosting (При разноске и обновлении), то выполняется проверка при сохранении записи (как изначально и было нужно - т.е. проверка будет выполнена ДО разноски - на этапе ввода (сохранения записи))
2. Теоретически, если вызвать из кода метод с 3-м параметром false, то можно добиться проверки только при сохранении (при этом значение в параметрах модуля может быть любым кроме Нет).

[d&m]

Цитата:

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

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

Для использования всего этого поставьте в параметрах главной книги параметр "Активировать наборы" (закладка Главная книга) в значение "При обновлении и разноске"

подскажите - в параметрах ГК я постваил Активировать наборы = Прир разнсоке, я настроил набор аналитик, настроил правила - для журнала ГК и для закупки.

в итоге - в закупке я могу сделать разноску без аналитик, в журнале ГК - без аналитик разноску сделать не могу. Это нормально? Разве тут не должно быть единообразия?

[sukhanchik]

Цитата:

Сообщение от d&m

в итоге - в закупке я могу сделать разноску без аналитик, в журнале ГК - без аналитик разноску сделать не могу. Это нормально? Разве тут не должно быть единообразия?

Извиняюсь - не сразу ответил - в заботах был.
В журнале ГК сделали очень досадный баг в виде "упущенного" конфигурационного ключа.
Дело в том, что в строке ЖГК (LedgerJournalTrans) существуют 2 набора аналитик: одни для счета (кстати - для корсчета никто аналитики и не думал делать почему-то) - это поле LedgerJournalTrans.Dimension и другие - для внутрихолдиногового учета.- поле LedgerJournalTrans.InterCoDimension.
Проверка соответствия иерархии аналитики осуществляется сразу для двух полей (см метод LedgerJournalTrans.checkDimensions()). В проверке честно поставлено условие, что если конфигурационный ключ иерархии аналитик включен - то проверку выполнять. НО! Никто не позаботился о том, что если ключ внутрихолдингового учета выключен - то проверку по внутрихолдинговым аналитикам делать не надо - т.к. их нет!
В связи с этим я изменил у себя код метода checkDimensions():

public boolean checkDimensions(boolean _checkWriteValidation)
{
    boolean             ok = true;
    DimensionSetCaller  dimensionSetCaller;
    ;

    if (isConfigurationkeyEnabled(configurationkeynum(DimensionSetHierarchy)))
    {
        dimensionSetCaller = DimensionSetCaller::construct(this, fieldnum(LedgerJournalTrans, Dimension));
        ok = appl.dimensionSetValidation(false, dimensionSetCaller.getCompanyId()).checkDimension(this,
                                                                                                  fieldnum(LedgerJournalTrans, Dimension),
                                                                                                  _checkWriteValidation) && ok;
        if (isConfigurationkeyEnabled(configurationkeynum(LedgerAdvIntercompanyAccounting))) // Вот здесь не хватает проверки на конфигурационный ключ
        {
            dimensionSetCaller.parmDimensionFieldId(fieldnum(LedgerJournalTrans, InterCoDimension));
            ok = appl.dimensionSetValidation(false, dimensionSetCaller.getCompanyId()).checkDimension(this,
                                                                                                      fieldnum(LedgerJournalTrans, InterCoDimension),
                                                                                                      _checkWriteValidation) && ok;
        }
    }

    return ok;
}

Проверьте - у меня не Ваш ли случай был?