Текущие компоненты

Название продукта Название компонента Тип Последняя версия Дата выхода
Галактика ERP 9.1L_KATORGRES

Справка по компоненту.

Количество версий компонента243
Количество рещенных задач627
Последная дата обработки компонента2023-12-17 16:43:00
Последная дата файла2023-12-16 17:31:34
Последная версия9.1.150.0

Новые задачи в этом компоненте

L_KATORG
102.193167
L_KATORG ( 9.1.089.0 )

Краткое описание :

Некорректно работает выбор организаций

Описание :

Аналитический учет

Что измененно :


Некорректно работает выбор организаций.
Формируем отчет, по счету ведется системная аналитика Организации, хотим выбрать нужные нам,открывается выбор по контрагентам, по умолчанию в настройках установлено отображение только Рабочих контрагентов.
В списке контрагентов они разбиты на несколько групп, становимся на нужную, нажимаем Insert помечается пака и все вложенные рабочие контрагенты, нажимаем ввод.
Но при этом почему-то в фильтр и в шапку отчета, соответственно, попадают организации, которые относятся к данной группе, но находятся в архиве.
Клиент утверждает, что ранее помечались и попадали в фильтр только те рабочие организации, которые отражались в интерфейсе выбора.

Как измененно :


Исправлено.
Также учитывается фильтр по стране и городу, если есть
L_KATORG
102.195388
L_KATORG ( 9.1.089.0 )

Краткое описание :

Модифицируются лишние МЦ при редактировании Справочника ОКДП2

Описание :

Каталог МЦ

Что измененно :


Создаем новую мц МЦ_1. Поле "Код ТНВЭД" (KATMC.TNVED) не заполняем.
Создаем новую мц МЦ_2. Становимся в поле "Код ОКПД2", жмем F3, попадаем в интерфейс L_KATORG::GETOKDP. Далее создаем новую запись. Если в ней заполнить поле ТНВЭД, то в МЦ_1 поле KATMC.TNVED заполнится этим же значением.
Такого быть не должно.

Т.е. если мы создаем в каталоге кодов ОКПД2 новую запись и присваиваем ей поле ТНВЭД, то во всех МЦ, где не заполнен код ТВНЭД происходит апдэйт поля KATMC.TNVED.
И вообще, зачем апдэйтить все МЦ, у которых код ТНВЭД совпадает с кодом ТНВЭД редактируемой в данный момент записи ОКДП2? Может быть лучше апдэйтить только те МЦ, которые ссылаются на редактируемый ОКДП2?

Как измененно :


Исправлено заполнение ТНВЭД в МЦ, если они не заданы при создании новой записи в каталоге ОКДП
L_KATORG
101.64791
L_KATORG ( 9.1.089.0 )

Краткое описание :

C 01.07.2018 ЦБ РФ вводит новый формат распространения справочника БИК 595-П

Описание :

Импорт каталога банков

Что измененно :


C 01.07.2018 ЦБ РФ вводит новый формат распространения справочника БИК
Формат DBF будет поддерживаться до конца года.

Необходимо реализовать импорт.

Как измененно :


ФРО-настройка-импорт каталога банков.
Реализован импорт справочника БИК с сайта ЦБРФ в формате XML.
Поля, для которых реализован перенос данных:
-Бик
-ОГРН
-Наименование
-Индекс
-Название населенного пункта
-Адрес
-Корр. счет.
По умолчанию загружается интерфейс для обработки данных с 01.01.2019.
В локальном меню есть возможность переключения для загрузки данных из формата DBF до 31.12.2018.
L_KATORG
101.66435
L_KATORG ( 9.1.089.0 )

Краткое описание :

(ВАН) Количество Parse превышает количество Executions

Описание :

Не знаю, какая именно часть контура логистики, научите

Что измененно :


Количество Parse превышает количество Executions
На основании awrrpt_1_43763_43764.html от 28-Dec-18 11:00 за 1 час работы на первой ноде.
Модуль: atlexec.exe
Запрос
SELECT COUNT(ROWID) FROM GAL_VEK."KONTRIER"
Описание
Количество Parse Calls составляет 25 тысяч раз. При этом количество выполнений этого запроса всего 1300 раз.
Либо разработчики парсят запрос, а на выполнение не запускают, либо выполнение идет с использованием parallel query. Таблица имеет degree = 1, а все индексы имеют degree = 30. Очевидно, что count считается по одному из индексов построенных по not null полям.
Рекомендация для Асконы
Запрос выполняется 7 раз в секунду в течение часа. В таблице 6 миллионов записей. Этот запрос делает избыточную и ни кому не нужную нагрузку на диски.
Обратите внимание, parallel query ВСЕГДА читает с диска игнорирую buffer pool.
Для облегчения ситуации таблица ранее была уже сжата методом BASIC. Рекомендую пересжать ее методом OLTP.
Для этого выполните fix_kontrier.sql
Это снизит размер таблицы на 30%, соответственно дисковые чтения снизятся также.
Рекомендация для разработчиков
Данный запрос выполняется 7 раз каждую секунду. Действительно ли необходимо так часто подсчитывать количество записей в таблице в которой 6 миллионов записей?
Пожалуйста, рассмотрите возможность кеширования данного вычисления на клиенте, чтобы этого не происходило 7 раз в секунду в течение часа.
При указании хинтовне забудьте, что parallel query это всегда дисковые чтения. Это всегда на тестовом окружении показывает хороший результат на секундомере, а на продуктивной БД будет просто "убивать" дисковую подсистему и тормозить расчет других задач выполняемых на этом сервере в это время.
Рассмотрите отказ от parallel query для этого запроса - подсчет count все-равно идет по индексу, он может быть в кэше и расчет будет выполняться гораздо быстрее без parallel query. Но это верно только для продуктива. На тесте секундомер покажет обратный результат, так как на тесте мало кто работает и там пустой кеш.
PS.Вариант, при котором вы парсите запрос, но не выполняете его - не рассматриваю, как маловероятный.

Как измененно :


Изменен алгоритм определения наличия записей в таблице с RecordsInTable на RecordExists

9.1.150.09.1.149.09.1.148.09.1.147.09.1.146.09.1.145.09.1.144.09.1.143.09.1.142.09.1.141.09.1.140.09.1.139.09.1.138.09.1.137.09.1.136.09.1.135.09.1.134.09.1.133.09.1.132.09.1.131.09.1.130.09.1.129.09.1.128.09.1.127.09.1.126.09.1.125.09.1.124.09.1.123.09.1.122.09.1.121.09.1.120.09.1.119.09.1.118.09.1.117.09.1.116.09.1.115.09.1.114.09.1.113.09.1.112.09.1.111.09.1.110.09.1.109.09.1.108.09.1.107.09.1.106.09.1.105.09.1.104.09.1.103.09.1.102.09.1.101.09.1.100.09.1.99.09.1.98.09.1.97.09.1.96.09.1.95.09.1.094.09.1.093.09.1.92.09.1.092.09.1.91.09.1.091.09.1.90.09.1.090.09.1.89.09.1.089.09.1.88.09.1.87.09.1.086.09.1.86.09.1.085.09.1.85.09.1.084.09.1.84.09.1.83.09.1.083.09.1.082.09.1.82.09.1.81.09.1.081.09.1.080.09.1.80.09.1.079.09.1.79.09.1.78.09.1.078.09.1.77.09.1.077.09.1.76.09.1.75.09.1.075.09.1.74.19.1.074.09.1.74.09.1.073.09.1.73.09.1.072.09.1.72.09.1.071.09.1.71.09.1.070.09.1.70.09.1.69.09.1.069.09.1.068.09.1.68.09.1.067.09.1.67.09.1.066.09.1.66.09.1.065.09.1.65.09.1.064.09.1.64.09.1.63.09.1.063.09.1.62.09.1.062.09.1.61.09.1.061.09.1.60.09.1.060.09.1.59.09.1.058.09.1.58.09.1.57.19.1.057.09.1.57.09.1.56.19.1.056.09.1.56.09.1.55.09.1.055.09.1.054.09.1.54.09.1.53.09.1.053.09.1.052.09.1.52.09.1.051.09.1.51.09.1.50.09.1.050.09.1.49.19.1.49.09.1.049.09.1.048.09.1.48.09.1.047.09.1.47.09.1.46.19.1.046.09.1.46.09.1.45.09.1.045.09.1.44.09.1.044.09.1.43.09.1.043.09.1.42.09.1.042.09.1.41.09.1.041.09.1.040.09.1.40.09.1.039.29.1.39.09.1.039.09.1.38.09.1.038.09.1.037.09.1.37.09.1.36.09.1.036.09.1.35.09.1.035.09.1.034.09.1.34.09.1.033.09.1.33.09.1.32.09.1.032.09.1.031.09.1.31.09.1.30.09.1.030.09.1.29.09.1.029.09.1.28.09.1.028.09.1.27.19.1.027.09.1.27.09.1.026.09.1.26.09.1.25.09.1.024.09.1.24.09.1.023.09.1.23.09.1.22.09.1.022.09.1.21.09.1.021.09.1.20.09.1.020.09.1.19.09.1.18.09.1.018.09.1.17.09.1.017.09.1.016.09.1.16.09.1.15.09.1.015.09.1.014.09.1.14.09.1.013.09.1.13.09.1.12.09.1.012.09.1.011.09.1.11.09.1.10.09.1.010.09.1.009.09.1.9.09.1.008.09.1.8.09.1.007.09.1.7.09.1.6.09.1.006.09.1.5.09.1.005.09.1.4.09.1.004.09.1.003.09.1.3.09.1.002.09.1.2.09.1.1.09.1.001.0