Проверьте версию плагина КриптоПро. Версию плагина из браузера можно посмотреть здесь: https://www.cryptopro.ru/sites/default/files/products/cades/demopage/simple.html. Если работать с подписью планируется в IE или FireFox, можно попробовать обновить плагин до версии 2, если в Chrome, то пока максимум 1.5
Смысл проблемы разворота в следующем:
Скиф 3 хранил данные вертикально, т.е. номер колонки там был таким же реквизитом, как атрибуты шапки или код строки:
Где A и B это реквизиты шапки, Row - код строки, Column - колонка, а X - это сумма. Т.е. каждая ячейка хранилась в отдельной строке таблицы БД. Например для одной строки одного документа, в котором есть три колонки с данными (3, 5 и 7 рублей, допустим) у нас было бы три записи:
Таким образом в аналитике никаких проблем с манипуляцией колонкой как отдельным измерением не возникало.
В Скифе БП хранилище горизонтальное. Т.е. одна строка формы - одна строка в БД. Те же самые цифры в Скифе БП хранятся так:
Тут то и возникает проблема с манипуляцией колонкой как отдельным измерением. Номера колонки то, как такового, больше нет.
Развернуть данные обратно в вертикаль можно несколькими способами. Самый простой из них – оператор union. Имея на руках одну строку, нужно обратится к ней три раза и результат сложить в одну таблицу:
Видите? Обращение идёт последовательно к трём колонкам и попутно рождается номер колонки, как отдельный атрибут.
В нашей аналитичке есть два способа употребить оператор union:
1. Собственно кубик «Объединение таблиц». Он предназначен именно для применения оператора union. Цель этого кубика, как раз, объединять несколько результатов в один.
2. Универсальный кубик SQL скрипт. Им можно делать, вообще, всё что угодно. В т.ч. то, что делает кубик «Объединение таблиц». Для его применения делаем следующее. Создаём последовательность кубиков:
В теле SQL кубика задаём следующую инструкцию:
Видно, что эта инструкция делает три запроса к одним и тем же данным формы и вываливает результат в таблицу Form_42801_Data_New.
Далее определяем кубик Кросс-Таблица. Ему на вход даём таблицу, произведённую SQL кубиком. А измерения задаём так:
Видно что номер колонки пошёл в строки, а единственная колонка с данными – в область с данными.
При нормальном течении процесса формирования НСИ на вашем сервере такие сообщения появляются только с том случае, когда пользователи захотят отказаться от обновления какого-либо показателя и, для этого, устанавливают себя (с высшим приоритетом) владельцем этой строки. Т.е. это сознательное действие пользователя и вопросов, в этом случае, не возникает.
Однако, как выяснилось, в процессе ведения НСИ в Скифе 3 некоторые строки, по каким-то причинам, которые сейчас уже выяснить не представляется возможным, обрели признак "локальных". Т.е. их правили на сервере пользователя. При миграции признак показателя "локальный" из Скифа 3 превратился в локального владельца с большим приоритетом в Скифе БП. Такие случаи подлежат исправлению, поскольку, завладение этими строками является непреднамеренным и препятствует их централизованному обновлению.
Для того, чтобы исправить эту ситуацию нужно:
Вопрос про фильтры на интервалы с возможностью получать интервалы НЕ ПОДРЯД до сих пор горячо обсуждается среди разработчиков. Нужно ли усложнять фильтр или нет? Пока единого мнения нет.
Например, в аналитичке требуется сравнить два месячных отчёта: декабрь 2012 и декабрь 2013.
Сейчас выходов два:
1. Дополнительным кубиком "SQL скрипт" удалить лишнее. Фильтр на источник задаётся как Дата начала 01.12.2012 - Дата окончания 01.01.2013. Нам, очевидно, мешают 11 лишних месяцев, т.е. все, у которых дата окончания действия не равна 01.01.2013 или 01.01.2014. Удалить их можно инструкцией:
2. Создавать два источника для одной и той же формы, но с двумя разными фильтрами. У данного способа, по сравнению с первым способом есть недостаток. У пользователя придётся запрашивать 4 даты, вместо 2х.
Скиф БП можно устанавливать на SQL 2005 и выше.
Скиф 3 можно устанавливать на 2000 и выше. Однако мы настоятельно рекомендуем устанавливать максимальную версию SQL, которая доступна для Вашей ОС на момент развёртывания программного комплекса. Для Windows XP это SQL 2008R2, для Windows 7 - это SQL 2012. Причём, рекомендуем выбирать разрядность SQL сервера соответствующую разрядности ОС, т.е. не ставить 32х разрядный SQL на машины с 64х разрядной ОС, т.к. при наличии более 3Гб оперативной памяти возможны проблемы.
Скиф БП можно устанавливать на PostgreSQL 14.3 и выше.
Рекомендуемые системные требования: https://postgrespro.ru/docs/postgrespro/15/binary-installation-on-linux
РЕКОМЕНДУЕМЫЕ АППАРАТНЫЕ ТРЕБОВАНИЯ:
Процессор: 8 ядер, тактовая частота 2.90 ГГц и выше.
Платформа: 32-х или 64-х разрядная.
Оперативная память: 32 ГБ и выше.
Жесткий диск: размер определяется объемом базы данных, но не менее 1 ГБ свободного дискового пространства