F_OS
Краткое описание :
Долго идет расчет амортизацииОписание :
АмортизацияЧто измененно :
У клиента очень долго выполняется процесс расчета амортизации.
Краткое описание действий
\\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_OS
Краткое описание :
Необходим запрет работы в модуле ОС при переходе к следующему либо возврату к предыдущему месяцуОписание :
Новый месяцЧто измененно :
Проблема:
При переходе к следующему месяцу не все карточки ОС совершают переход. Часть остается в предыдущем периоде.
Происходит - если во время перехода в модуле работают прочие клиенты. Получают отчеты или работают с картотекой (фильтры и пр.)
Тестирование у двух клиентов РУП Белтелеком показало, что переход завершается успешно если никого нет в модуле.
Размеры картотеки от 50 до 200 тыс. И переход занимает немало времени.
Простейшее решение - запрет.
Как измененно :
Добавлена настройка
"Настройки Галактики \ Бухгалтерский контур \ Учет ОС и НМА \ Запретить вход в модули "ОС" и "НМА" при переходе к новому периоду"
Если она установлена в ДА, то при переходе на следующий период проверяется наличие пользователей
в модуле (проверяется захват лицензий). И если их больше одного, то переход не осуществляется.
Также в процессе перехода пользователи не смогут зайти в модуль ОС или НМА.
F_OS
Краткое описание :
При настройке "Формировать протокол=нет" протокол по ошибкам формируетсяОписание :
АмортизацияЧто измененно :
При настройке "Формировать протокол=нет" протокол по ошибкам формируется.
При расчете разниц из интерфейса "Амортизация" (функция локального меню
"Расчет разницы данных по методам учета") даже при установленной настройке
"Формировать протокол=нет", если есть ошибки при расчете разниц, то протокол формируется.
Как измененно :
Исправлено. Протокол не формируется.
F_OS
Краткое описание :
отбор ИК имеющих амортизационную льготуОписание :
Ведение картотекиЧто измененно :
отбор ИК имеющих амортизационную льготу:
- есть амортизационная льгота
- амортизационная льгота в конкретном периоде
Как измененно :
Для России:
В интерфейс "Отбор инвентарных карточек" в поле "Отбор объектов" добавлен параметр "с амортизационной льготой". Данный параметр позволяет отобрать ИК которые имеют проведенную операцию с установленной амортизационной льготой. Данный параметр отбора можно использовать вместе с заданием периода отбора. Период отбора в этом случае будет задан по дате возникновения льготы.
F_OS
Краткое описание :
Название главного меню "Материально ответственные лица"Описание :
Материально-ответственные лицаЧто измененно :
Убрать дефис: Материально ответственные лица (см. модули "Настройка" и "Складской учет" - там верно).
Как измененно :
Исправлено.
F_OS
Краткое описание :
Ошибка, после конфигурирования окна, значения выбираются не из того каталога.Описание :
Ведение картотекиЧто измененно :
Ошибка, после конфигурирования окна, значения выбираются не из того каталога.
См вложение.
Как измененно :
Исправлено. После конфигурирования окна, значения выбираются из нужного каталога.
F_OS
Краткое описание :
Цена в приходном ордере, сформированным по реализацииОписание :
ВыбытиеЧто измененно :
Учет ОС - Операции - Выбытие. В сформированном в результате реализации приходном ордере встает цена, равная остаточной стоимости. Если износ начислен полностью, то она равна нулю. Клиент просит реализовать возможность, при которой в приходный ордер будет попадать цена продажи. Возможно настройкой или дополнительным пунктом в параметрах реализации.
Как измененно :
В закладке Параметры сопроводительных документов добавлен параметр - "Цена приходного ордера равна".
Он может принимать два значения - Остаточной стоимости или Стоимости продажи.
F_OS
Краткое описание :
Обрабатывать в OSNMA те позиции, в которых аморт. ОС равна 0 но не0 разницыОписание :
Другие интерфейсы по ОСЧто измененно :
Есть случаи, когда амортизация в НУ равна 0, но по ОС продолжают списываться разницы.
В случаях, когда амортизация 0 в НУ, ТХО по амортизации, включающее проводки по разницам вообще не отрабатывает.
Чтобы преодолеть данную проблему была придумана опция "[.] фильтр по нулевому износу за месяц".
Нельзя назвать данное решение однозначно удачным, есть следующие недостатки:
1) требуется дублировать и поддерживать проводки по разницам еще и для бухгалтерского метода учета.
2) дубли провдодок по разницам для бухгалтерского учета иногда дают ложное срабатывание по разницам (когда неопытный пользователь считает амортизацию только по БУ), амортизация в НУ при этом 0 и формируются проводки которые не должны были формироваться.
3) не всегда удается получить нужные аналитики карточки ОС см. ПИР 180.6796
ПРЕДЛАГАЮ
доработать систему таким образом, чтобы ТХО по амортизации выполнялись (я так полагаю, что должна быть доработана не ТХО, а операция амортизации и должен создаваться SpMoveOS) даже в том случае, если амортизация НУ равна 0, но при этом разницы, отражаемые в текущем периоде, ненулевые. Стоит ли анализировать ли сальдо по разницам на неравенство нулю, нужно подумать коллективно.
Как измененно :
Добавлена настройка "Настройки Галактики \ Бухгалтерский контур \ Учет ОС и НМА \ Настройка операций \ Амортизация \ При расчете амортизации создавать записи с амортизацией равной нулю"
Она может принимать значения
'нет'
'если ненулевое входящее сальдо по разницам'
'с учетом признака использования'
'да'
Записи SpMoveOs с амортизацией равной нулю создаются в зависимости от настройки.
F_OS
Краткое описание :
Неединообразный подход к разницам в OSNMAОписание :
Корректировка разницЧто измененно :
Все показатели касающиеся разниц, в частности ВВРНМ, НВРНМ, СписВВРНМ, СписНВРНМ, ПРНМ и т.д. в OSNMA не умножались на количество из карточки, т.е. предполагалось как бы ведение разниц в целом на карточку, вновь добавленные показатели 'КорНВВР', 'КорПВВР', 'КорННВР', 'КорПНВР', 'КорНПР' почему-то умножаются на количество из карточки, что вносит неединообразие и неразбериху в написание ТХО по разницам.
Показатели 'КорНВВР', 'КорПВВР', 'КорННВР', 'КорПНВР', 'КорНПР' нужно выводить в OSNMA без умножения на количество.
Как измененно :
\r\nДобавлена настройка \"Настройки Галактики \\ Бухгалтерский контур \\ Учет ОС и НМА \\ Настройка операций \\ Амортизация \\ При расчете амортизации создавать записи с амортизацией равной нулю\"\r\nОна может принимать значения\r\n \'нет\'\r\n \'если ненулевое входящее сальдо по разницам\'\r\n \'с учетом признака использования\'\r\n \'да\'\r\nЗаписи SpMoveOs с амортизацией равной нулю создаются в зависимости от настройки.\r\nF_OS
Краткое описание :
Множественное создание StoimStruct с кодом 1500 в ходе перепровения операцийОписание :
Изменение параметровЧто измененно :
Введена операция изменения параметров, в которых StoimStruct никоим образом не менялся (StoimStruct с кодом 1500 в операцию не вставлялся)
Пользователь откатил одну карточку из этой операции на месяц назад, а потом на месяц вперед.
Осуществилось перепроведение операции и в ходе перепроведения произошло массовое создание StoimStruct с кодом 1500 для всех карточек в операции.
Зачем вставились с StoimStruct с кодом 1500 в случае перекатов карточки по периодам, не понятно. Вновь созданная запись оказывает вредное влияние:
1) забивает базу лишней информацией,
2) может вызвать ошибки в работе системы:
a. В операции отобъется текущее распределение по StoimStruct
b. Пользователь поменяет StoimStruct руками.
c. Откати назад.
d. Вернет вперед.
e. Его ручные правки пропадут в ходе перепроведения ранее добавленного StoimStruct = 1500
Ошибочное создание записей StoimStruct с кодом 1500 нужно утранить.
Как измененно :
Исправлено. Лишние записи не создаются.
Также должно быть установлено решение 180.8609
F_OS
Краткое описание :
Округление стоимости при реализации СпецодеждыОписание :
ВыбытиеЧто измененно :
При оформлении Реализации необходимо учитывать настройки округления
ROUND.SELL
"Настройки Галактики \ Логистика \ Документы \ Управление сбытом \ Округление в документах сбыта"
.
На данный момент работает так:
function SpDocBuf_SetAnotherPrice: boolean;
var wasError: boolean;
{
...
_loop SpMoveOsCur
// карточка спецификации операции Выбытие
if (GetFirst SpDocBuf where ((SpMoveOsCur.nRec == SpDocBuf.NRecSpStep)) = tsOk)
{
SpDocBuf.Price := SpDocBuf_GetPrice(TSpMoveOs(SpMoveOsCur.buffer), NastrOsCur.field4 = 1, false);
...
А хотело бы так, как это сделано при ручном создании "Накладной на отпуск" - с использованием Паскалевских функций округления, например fRoundRub2:
(файл _src\CompSrc\L\L_SoprDoc\vip\ChkSum.vpp)
//округление цены при включенной настройке
Procedure FSRoundPrice;
{
if (SpSopr.KolOpl <> 0)
if FSRoundRub(SpSopr.Price * SpSopr.KolOpl) <> (SpSopr.Price * SpSopr.KolOpl) OR
FSRoundVal(SpSopr.VPrice * SpSopr.KolOpl) <> (SpSopr.VPrice * SpSopr.KolOpl)
{
SpSopr.Price := FSRoundRub(SpSopr.Price * SpSopr.KolOpl) / SpSopr.KolOpl;
!!!НЕЛЬЗЯ ЭТОГО ДЕЛАТЬ SpSopr.rPrice := SpSopr.Price;
SpSopr.VPrice := FSRoundVal(SpSopr.VPrice * SpSopr.KolOpl) / SpSopr.KolOpl;
!!!НЕЛЬЗЯ ЭТОГО ДЕЛАТЬ SpSopr.rVPrice := SpSopr.VPrice;
}
}
Как измененно :
Округление производится согласно настройки
"Настройки Галактики \ Логистика \ Документы \ Управление сбытом \ Округление в документах сбыта".
F_OS
Краткое описание :
Утрата результата операции корректировка разниц в ходе отмены амортизацииОписание :
Корректировка разницЧто измененно :
Была реализована настройка, которая меняет подход к фиксации результатов операции корректировки разниц ("Настройки Галактики \ Бухгалтерский контур \ Учет ОС и НМА \ Налоговый учет \ Сразу проводить операцию корректировки разниц").
При значении "да" в этой настройке, операция корректировки применяется сразу, при этом в расчете амортизации эти операции уже не анализируются.
Однако при определенном стечении обстоятельств система дает сбой, когда результат применения операции корректировка разниц теряется.
Последовательность описана ниже.
1) Пришли в январь 2015.
2) Создали операцию корректировки разниц по ОС № 000001
3) Применили операцию корректировки разниц, получили в разницах скорректированное входящее сальдо.
4) Рассчитали амортизацию и разницы, при расчете оттлокнулись от измененного входящего сальдо. Всё хорошо!
5) Запустили отмену амортизации с галочкой "корректировать разницы"
6) Удалилась строчка в разницах со скорректированным входящим сальдо.
7) Запустили расчет амортизации и разниц заново.
8) Создалась срочка в разницах со нескорректированным входящим сальдо.
9) Операция применения корректировки разниц не запускалась, т.к. по новому функционалу, она не должна запускаться, т.к. считается что сальдо уже скорректировано.
10) Всё плохо: имеем нескорректированное входящее сальдо по разницам.
Нужно как-то изменить программу, чтобы в случае создания новой OsRazn она все таки применяла автоматически проведенную корректировку разниц, либо не удаляла OsRazn при отмене, либо несмотря на то что корректировка проведена, и всё теоретически должно быть хорошо, однако система при расчете разниц всё же перепроверяла, действительно ли всё хорошо, либо еще что-то.
Как измененно :
Исправлено. Если запись разниц по какой-либо причине была удалена, то при расчете амортизации она будет восстановлена вместе с операцией корректировки.
F_OS
Краткое описание :
Размножение записей OsRazn в результате повторного применения операции корректировки разницОписание :
Корректировка разницЧто измененно :
Создал операцию корректировки разниц.
Провел.
Отменил проведение.
Провел заново.
Захожу в карточку - вижу на закладке "Разницы" две записи от текущего месяца.
Если повторить отмену и проведение, добавится еще одна запись.
ОШИБКА!
Как измененно :
Исправлено. Записи не размножаются.