F_OSOPER
Краткое описание :
Долго идет расчет амортизацииОписание :
АмортизацияЧто измененно :
У клиента очень долго выполняется процесс расчета амортизации.
Краткое описание действий
\\BY01-FSRVCL01\share\atl_log\Транснефть-Восток
(Братск)\102.139260 Долго идет расчет амортизации
ОС\readme.txt
Подробное измерение расчета описано в файле:
\\BY01-FSRVCL01\share\atl_log\Транснефть-Восток
(Братск)\102.139260 Долго идет расчет амортизации
ОС\test1_22.12.2014\Запуск процедуры расчета
амортизации.docx. В ходе расчета амортизации
"вываливается" RunTime Error. Лог ошибки -
AmortError.OUT
Произведено протоколирования процесса расчета
амортизации средствами Atlantis в Sil протокол:
\\BY01-FSRVCL01\share\atl_log\Транснефть-Восток
(Братск)\102.139260 Долго идет расчет амортизации
ОС\test1_22.12.2014\ProtsenkoES_01_RuntimeError.zip
Также приведены снимки AWR отчета работы БД Oracle
в момент выполнения функций расчета:
\\BY01-FSRVCL01\share\atl_log\Транснефть-Восток
(Братск)\102.139260 Долго идет расчет амортизации
ОС\test2_22.12.2014_18-00\2014.12.23 AWR\
Как измененно :
Ускорена пометка карточек.
Ускорен расчет амортизации (на 10% для данной бд) за счет отказа от модификации поля KatOs.ModAmort
Это поле "состояние" в списке картотеки. Поле показывает какие операции были проведены над карточкой.
Для рассчитанной амортизации поле принимало значение "А".
Плюс улучшена визуализация и расчет амортизационной льготы. Это дало еще около 5%. Итого - 15%.
Расчет разниц данных вынесен после расчета амортизации. Это позволило ускорить расчет еще процентов на 10.
Общий итог ускорения около 20%.
Анализ показал, что до 70% процентов времени расчета амортизации уходит на расчет разниц.
Ускорить расчет разниц можно при помощи точки расширения описанной в проблеме 180.8428.
Ускорения можно достичь значительного даже только за счет создании/уничтожения объекта расчета разниц
Вот что у меня получилось на одной из БД.
До оптимизации
Этап "Расчет" амортизации
Время выполнения : 00:01:21:30
---------------------------------------
Время расчета РАЗНИЦ : 00:00:19:99
--------------------------------------------------------------------------------
Старт: 11/02/15 15:54:54 Стоп: 11/02/15 15:56:16
Время выполнения расчета амортизации. Период: 06.2009. 00:01:21:40
================================================================================
ГПосле оптимизации Г
Этап "Расчет" амортизации
Время выполнения : 00:00:53:39
-----------------------------------
Время расчета РАЗНИЦ : 00:00:03:12
--------------------------------------------------------------------------------
Время выполнения расчета амортизации. Период: 06.2009. 00:00:56:63
Видно что общее время улучшилось на 30%.
А время расчета разниц улучшилось в 5 раз.
F_OSOPER
Краткое описание :
Необходим запрет работы в модуле ОС при переходе к следующему либо возврату к предыдущему месяцуОписание :
Новый месяцЧто измененно :
Проблема:
При переходе к следующему месяцу не все карточки ОС совершают переход. Часть остается в предыдущем периоде.
Происходит - если во время перехода в модуле работают прочие клиенты. Получают отчеты или работают с картотекой (фильтры и пр.)
Тестирование у двух клиентов РУП Белтелеком показало, что переход завершается успешно если никого нет в модуле.
Размеры картотеки от 50 до 200 тыс. И переход занимает немало времени.
Простейшее решение - запрет.
Как измененно :
Добавлена настройка
"Настройки Галактики \ Бухгалтерский контур \ Учет ОС и НМА \ Запретить вход в модули "ОС" и "НМА" при переходе к новому периоду"
Если она установлена в ДА, то при переходе на следующий период проверяется наличие пользователей
в модуле (проверяется захват лицензий). И если их больше одного, то переход не осуществляется.
Также в процессе перехода пользователи не смогут зайти в модуль ОС или НМА.
F_OSOPER
Краткое описание :
Не всегда отрабатывает функция "Просмотр операции ОС" при включ. параметре Randomsurrkeys=onОписание :
ОС-овая сторона накладнойЧто измененно :
Не всегда отрабатывает функция "Просмотр операции ОС" при включ. параметре Randomsurrkeys=on
Для нового режима перевода объектов со склада в ОС "Создать новую простую ИК с учетом разных партий
МЦ" при включенном параметре Randomsurrkeys=on не всегда отрабатывает функция локального меню
"Просмотр операции ОС".
Как измененно :
Теперь будет всегда отрабатывать, при любом значении ключа Randomsurrkeys.
F_OSOPER
Краткое описание :
При настройке "Формировать протокол=нет" протокол по ошибкам формируетсяОписание :
АмортизацияЧто измененно :
При настройке "Формировать протокол=нет" протокол по ошибкам формируется.
При расчете разниц из интерфейса "Амортизация" (функция локального меню
"Расчет разницы данных по методам учета") даже при установленной настройке
"Формировать протокол=нет", если есть ошибки при расчете разниц, то протокол формируется.
Как измененно :
Исправлено. Протокол не формируется.
F_OSOPER
Краткое описание :
переоценка ОСОписание :
ПереоценкаЧто измененно :
Требуется проведения переоценки по ОС,у которых дата поступления отличается от даты ввода в эксплуатацию.
У нас теперь работает по дате ввода в эксплуатацию, а нужно по дате поступления.
Как измененно :
Для использования в скрипте переоценки добавлены фунции:
Ext_CheckExtAttr - позволяет определить имеет ли ИК внешний атрибут со значением отличным от нуля(внешний атрибут с типом "Вещественное число");
Ext_GetKoefNRecByDatOk - возвращает значение коэффициента переоценки на дату поступления ИК;
FreePereoc - функция освобождает интерфейс переоценки(служебная функция).
Пример скрипта для вычисления коэффициента:
// эти две строки ОБЯЗАТЕЛЬНЫ
// они нужны для использования вышеописанных функций
#include objscript.vih
VipInterface PereocScript implements objScript;
begin
var iScript : PereocScript;
if( iScript.Ext_CheckExtAttr('Дата поступления'))
Result := iScript.Ext_GetKoefNRecByDatOk;
else
Result := ShKoef.KoefDef;
//следующие две строки нужны для корректного вычисления переоценки
iScript.FreePereoc;
FreeVipInterFace(iScript);
end.
Пример скрипта для применения поправочного коэффициента(в данном примере равен 0,7) на дату поступления:
#include ObjScript.vih
VipInterface PereocScript implements objScript;
begin
var iScript : PereocScript;
var KoefDef : double;
var PostKoef : double;
KoefDef := 0;
PostKoef := 0;
KoefDef := ShKoef.KoefDef;
if( iScript.Ext_CheckExtAttr('Дата поступления'))
PostKoef := iScript.Ext_GetKoefNRecByDatOk;
if PostKoef <> 0
Result := PostKoef / KoefDef * 0.7;
else
Result := 0.7;
iScript.FreePereoc;
FreeVipInterFace(iScript);
end.
F_OSOPER
Краткое описание :
В протокол расчета амортизации при детализации "отладочная информация" стала заноситься неверная информация.Описание :
АмортизацияЧто измененно :
В протокол расчета амортизации при детализации "отладочная информация" стала заноситься неверная информация.
Есть 2 карточки с одинаковым алгоритмом начисления информации. По первой карточке рассчиталась амортизация, например 100. При расчете амортизации по второй карточке возникла ошибка: например, во второй карточке не задан признак использования. Вторая карточка попадает в протокол, но результат расчета по алгоритму выводиться из первой карточки = 100.
Как измененно :
Исправлено.
F_OSOPER
Краткое описание :
Цена в приходном ордере, сформированным по реализацииОписание :
ВыбытиеЧто измененно :
Учет ОС - Операции - Выбытие. В сформированном в результате реализации приходном ордере встает цена, равная остаточной стоимости. Если износ начислен полностью, то она равна нулю. Клиент просит реализовать возможность, при которой в приходный ордер будет попадать цена продажи. Возможно настройкой или дополнительным пунктом в параметрах реализации.
Как измененно :
В закладке Параметры сопроводительных документов добавлен параметр - "Цена приходного ордера равна".
Он может принимать два значения - Остаточной стоимости или Стоимости продажи.
F_OSOPER
Краткое описание :
Обрабатывать в OSNMA те позиции, в которых аморт. ОС равна 0 но не0 разницыОписание :
Другие интерфейсы по ОСЧто измененно :
Есть случаи, когда амортизация в НУ равна 0, но по ОС продолжают списываться разницы.
В случаях, когда амортизация 0 в НУ, ТХО по амортизации, включающее проводки по разницам вообще не отрабатывает.
Чтобы преодолеть данную проблему была придумана опция "[.] фильтр по нулевому износу за месяц".
Нельзя назвать данное решение однозначно удачным, есть следующие недостатки:
1) требуется дублировать и поддерживать проводки по разницам еще и для бухгалтерского метода учета.
2) дубли провдодок по разницам для бухгалтерского учета иногда дают ложное срабатывание по разницам (когда неопытный пользователь считает амортизацию только по БУ), амортизация в НУ при этом 0 и формируются проводки которые не должны были формироваться.
3) не всегда удается получить нужные аналитики карточки ОС см. ПИР 180.6796
ПРЕДЛАГАЮ
доработать систему таким образом, чтобы ТХО по амортизации выполнялись (я так полагаю, что должна быть доработана не ТХО, а операция амортизации и должен создаваться SpMoveOS) даже в том случае, если амортизация НУ равна 0, но при этом разницы, отражаемые в текущем периоде, ненулевые. Стоит ли анализировать ли сальдо по разницам на неравенство нулю, нужно подумать коллективно.
Как измененно :
Добавлена настройка "Настройки Галактики \ Бухгалтерский контур \ Учет ОС и НМА \ Настройка операций \ Амортизация \ При расчете амортизации создавать записи с амортизацией равной нулю"
Она может принимать значения
'нет'
'если ненулевое входящее сальдо по разницам'
'с учетом признака использования'
'да'
Записи SpMoveOs с амортизацией равной нулю создаются в зависимости от настройки.
F_OSOPER
Краткое описание :
Не понятное сообщение о переоценке фиксированной суммы амортизацииОписание :
ПереоценкаЧто измененно :
В ходе проведения операции переоценки иногда выводится такое сообщение
,'Для ИК с номером ' + KatOs.InNum
+ ' по методу учета "' + NastrOs.Name + '"'
+ ' установлена фиксированная сумма амортизации.'#13
+ 'Переоценить сумму амортизации по коэффициенту?'
В данном сообщении не понятна последняя фраза. Термин "сумму амортизации" воспринимается как накопленная амортизация в карточке, хотя на самом деле речь идет о переоценке "фиксированной ежемесячной суммы амортизации"
ПРЕДЛАГАЮ изменить последнюю фразу сообщения, чтобы было понятно о чем речь, например вместо "сумму амортизации" использовать "фиксированную ежемесячную сумму амортизации"
Как измененно :
Сообщение исправлено.
F_OSOPER
Краткое описание :
Ошибочное перепроведение операции переоценкаОписание :
ПереоценкаЧто измененно :
В периоде 12.2014 создана операция переоценки с количеством ОС > 1.
Операция переоценки проведена.
Откатили одну карточку ОС из числа включенных в Операцию переоценки на несколько периодов назад.
Прокатили карточку обратно в период 12.2014.
В результате автоматического применения операций в расширенной информации карточки ОС ПОВТОРНО применились суммы переоценки стоимости и износа из операции переоценки по ВСЕМ карточкам, присутствующим в операции переоценки. (Должно было сделаться только по одной карточке, которую откатывали в прошлый период). Данная ошибка делает поля "Накопленная переоценка стоимости" и "Накопленная переоценка износа" из расширенной информации карточки неверными, ломает данные.
ОШИБКУ нужно устранить.
Как измененно :
Исправлено. Поля накопленные суммы переоценки стоимости и износа при перепроведении операции
заполняются верно.
Теперь перепроведение идет только по отмеченным карточкам. Раньше шло по всем карточкам из операции.