[Logo] Форум ПАРУС
Сообщения, отправленные пользователем: CYMEPKU
Индекс форума » Профиль для CYMEPKU » Сообщения, отправленные пользователем CYMEPKU
Автор Сообщение
del
в схеме XSD реестра 1.7.7 есть xs:sequence. поэтому важна последовательность появления тэгов в выгрузке.
REF_NPAY_FATHER_NO
REF_NPAY_FATHER_DT
REF_NPAY_MOTHER_NO
REF_NPAY_MOTHER_DT
REF_NPAY_WORK_NO
REF_NPAY_WORK_DT
например, были не на месте, они должны быть ниже в выгрузке.
Отсюда ошибки "Элемент "ROW" имеет недопустимый дочерний элемент"
Подвинул строчки вверх в выгрузке, файл на основе выше выложенного прикрепил

ADDR_GUID возможно из этой же серии

PS Да, ADDR_KLADR и ADDR_GUID надо местами поменять
Проверка увязки в остатках планируется к доработке?
Присоединюсь
WELGA wrote:LOLO Попробовали сформировать за январь только для проверки корректного заполнения (числен.1000чел.) общая сумма не идет на 200 тыс. начали сверять уже на букве у двоих однофамильцев зарплата не сответствует начислению оклад одного тянется другому а другого непонятно откуда тянется оклад
Проверьте входимость в группу. Обязательно должен быть символ +


При отсутствии "+" наоборот суммы попадают несколько раз и по периоду "за" и "в"
Возможно проблема в пересчетах по закрытым к началу 2020 года ЛС.
Попробуйте. Переписывал чтобы такие ЛС попадали
KMS wrote:Поймали, что л/с, у которых график работы не стоит тоже в отчет не попадают! Проверяйте графики в л/с


а уж про начисления на ЛС недействующие в 2020 году вообще наверное не стоит спрашивать?)
MKARPOW wrote:
CYMEPKU wrote:Ошибку про численное переполнение кто-нибудь победил?

Oшибка N 39 Численное переполнение. Данные потеряны.
Переполнение
В строке 0
Последовательность вызовов:
..
PROCEDURE AR_GOSMUNSAL.PRINTALL
PROCEDURE AR_GOSMUNSAL.GETFCACDATA

только на определенных подразделениях


Такая же ошибка!
Пока очистил окно подразделений и стал работать через группу лицевых счетов.
Методом поиска нашел конкретные лицевые счета, которые не хотят идти в отчет и дают ошибку.
Организация 1500 человек, ошибок около 5. Подразделение ошибок не дает, дело в лицевых счетах.
Пока только не понятно - чем эти лицевые не нравятся и как исправлять?
Если кто разобрался - напишите хоть что-то.


У меня это был коэффициент 100 в стаже. в итоге стаж получился 1500 лет и отчет вылетел. 1 человек
Ошибку про численное переполнение кто-нибудь победил?

Oшибка N 39 Численное переполнение. Данные потеряны.
Переполнение
В строке 0
Последовательность вызовов:
..
PROCEDURE AR_GOSMUNSAL.PRINTALL
PROCEDURE AR_GOSMUNSAL.GETFCACDATA

только на определенных подразделениях
IRINA48 wrote:Oшибка N 39 Численное переполнение. Данные потеряны.
Постоянно вылетает база. Численность всего 60 человек. Даже на подразделение оно, чуть больше настроек подтянешь, вылетает


похожая ситуация, но для одного из подразделений.. видимо некорректные записи в таблице начислений. буду пробовать вечером коррекцию.
Наконец удалось победить заразу "Трафарет готовится". Причина оказалась в символах перевода строки в текстовых ячейках трафарета. CTRL+H ->> CTRL+J ->> пробел ->> заменить все ->> перестартовать веб с очисткой кэша трафаретов ->> профит

Мысль была тут https://info.parusyug.ru:8443/pages/viewpage.action?pageId=2686982
Вроде бы поправили в релизе 12.20. Будем проверять
Спасибо, так и сделаем
CHEREDNIK_AD wrote:
форма 0504035 (52н) у меня сформировалась по счетам ОС из оборотки по тмц

в редакции 194н пустая


у меня ф.0503035 обе не вышли, выходит обычная старая оборотка "Оборотная ведомость по ТМЦ"
Спасибо. Один вопрос снял. К форме из ИК, правда, есть вопросы в соседнем посте
Оборотка по ОС ф.0503035 из оборотной ведомости по ТМЦ по счетам ОС выходит пустая. Это нормально?

Обычная форма оборотки по ТМЦ без ОКУД данные выводит.

Предполагается, что данные ОС можно взять только из отчета ф.0503035 из инв.картотеки?
При списании из групповой карточки (в окне группового состава) все операции проходят как частичное списание, а последняя - как просто списание. Во первых это количество проводок в правиле отработки увеличивает в 2 раза.. Но это можно пережить.
Но отражение результата этих операций в форме оборотки 0503035 из инв.картотеки проходит некорректно. Последняя карточка из группового состава остается в остатках ка конец. Релиз П8 бюджет май 2020. Поправили этот момент в последних релизах?
Т.к. это единственный вариант вывода регламентированной оборотки по ОС из П8 (из оборотки по ТМЦ вроде бы не выводит ОС), странно, что проблема осталась с 2015 года (столько ведь лет 52н? )
Или все пользуются только карточками ОС-6?
Продолжу тему. Штатный набор таблиц и процедур переноса работает, но ограничен в основном кадровым/зарплатным модулем и остатками бухгалтерии. Только самое необходимое.
Получается, что перенос можно проводить исключительно с нового года, это грустно.
Но при этом сам механизм вроде бы понятен и легко расширяем. По сути те же знакомые таблицы П7 + удобный набор процедур для добавления в разделы П8. Промежуточное складирование данных не нужно. Добавляем таблицу П8, соответствующую структуре таблицы в П7 - и на первом этапе загрузки из базы П7 она окажется в базе П8. Добавляем процедуру, которая обработает загруженные DBF - и данные попадут в соотв. разделы.
Вопрос в том, что с 2013 года, когда этот функционал как я понял был выпущен, разработчиком он не был расширен в достаточной степени для переноса документарных разделов. В первый раз пару лет назад когда столкнулся с переводом на П7-->>П8, я доделал (на основе наработок товарища Mazdik) разделы касс. и банковские документы. Вроде бы все прилично получилось и даже связь и с ХО установилась.
Я подозреваю, что тем же самым занимаются все, но каждый в своей песочнице. И где-то по закромам уже лежат все необходимые процедуры.

Мне интересны в первую очередь связка ГК+БО+ВнутрДок. Вокруг них в данных момент вертится весь учет. Без них перенос в течение года в принципе невозможен.

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

Убрать иерархию в плане счетов как я понял можно так:


Просто при заведении новых счетов периодически повторять (как вариант повесить ПП на после добавления счета с очисткой иерархии - не пробовал)
Вариант переписывать вьюху как-то меньше нравится

Подтверждаю, после описанных процедур план счетов летает

UPD. Очистка иерархии выходит боком при удалении счетов. Значит только правка вьюхи каждый раз при обновлении
Спасибо, буду копать в этом направлении
После переноса из П7 все счета получили свою копию в виде зеленого каталога в котором ничего нет. Наверное это нужно для какой-то серьезной цели, хотя как по мне - обычная каталожная структура вполне решает все задачи. Очень кажется, что жесткое торможение при отборе в плане счетов в режиме списка (около 10 тыс.позиций) связано именно с этой иерархией. Параметр 870 - пустой. Перейти на 9 символов не вариант.
1. Можно ли привести план счетов к внешнему виду 7ки?

2. Где почитать про "Установка иерархической структуры плана счетов" ? Раздел справки очень краток ("Данный параметр - необязательный, соответственно в случае его отсутствия (пустое поле шаблона) - иерархическая структура плана счетов в Системе не используется.") У меня параметр 870 отсутствует - но иерархия в ПС есть и не радует

На всякий случай чтобы было. Ошибка выходит при выгрузке данных первичного отчета сводов в Excel. Ошибка из-за вводимых значений, которые неверно понимаются Excel. Например в текстовом показателе при общем формате ячейки заведен текст очень похожий на формулу - "=12*12=244". Решается форматом ячейки - изменить на текстовый. Еще были варианты с показателями даты и неверно сохраненными значениями типа 01.01.202.
Обычно если эта ошибка выходит в вебе, то такая же ошибка выходит в макросе при открытии отчета в вин-приложении, тогда помогает кнопка DEBUG.

Я правильно понимаю, что мониторинг у Вас не формируется?


да. валится с ошибкой

Oшибка N 12 Переменная 'WRKI' не найдена.
Переменная не определена
В строке 0
Последовательность вызовов:
D:\PARUSDB\PARUS\SALARY\SALARY.EXE
PROCEDURE ZFACEACC_MC.MASTERPANEL.GRIDPANEL.GRID._USERCOLUMN1.GRIDTEXT1.MOUSEUP
PROCEDURE ZFACEACC_MC.MASTERPANEL.GRIDPANEL.GRID.MOUSEUP
PROCEDURE ZFACEACC_MC.MASTERPANEL.GRIDPANEL.GRID.SHOWMENU
PROCEDURE ZFACEACC_MC.MASTERMENU.SHOWMENU
ON...
PROCEDURE ZFACEACC_MC.MASTERMENU.EXECCOMMAND
PROCEDURE ZFACEACC_MC.MASTERPANEL.GRIDPANEL.GRID.RECEIVEMESSAGE
PROCEDURE TGRID.RECEIVEMESSAGE
PROCEDURE AR_MEDMONSAL D:\PARUSDB\PARUS\SALARY\FOX\AR_MEDMONSAL.APP
PROCEDURE AR_MEDMONSAL.BTNGROUP.BUTTONVIEW.CLICK
PROCEDURE AR_MEDMONSAL.PRINTALL
PROCEDURE AR_MEDMONSAL.PRINTFORM.ZAR_FORMEXCEL
PROCEDURE AR_MEDMONSAL.PRINTFORM.PRINTDOCUMENT_FREE
PROCEDURE AR_MEDMONSAL.GETFCACDATA
PROCEDURE AR_MEDMONSAL.GET_SUM
PROCEDURE AR_MEDMONSAL.GET_COST
ON...

просто мы ее исправляли сами
Отвечу сам себе. Копирование и вставка не распределяет по строкам и столбцам если в формате ячейки трафарета стоит "переносить по строкам". Если убрать - все работает и можно копировать готовые диапазоны из Excel в первичный отчет.
Отдельный момент - содержимое каждой копируемой ячейки не должно содержать символы переноса строки - иначе разойдется на 2 строки. Это решается подготовкой копируемых данных, удалением символов переноса. Первая ссылка по запросу "Тонкости работы с переносами строк в Excel"
TEST wrote:
CYMEPKU wrote:Из релиза в релиз идет ошибка при обработке начислений распределенных по группам составов затрат
Oшибка N 12 Переменная 'WRKI' не найдена.
...
PROCEDURE AR_MEDMONSAL.GET_COST
в процедуре

а должно быть



В последней версии мониторинга это распределение уже не актуально


APP от ‎2 ‎февраля ‎2021 ‎г., ‏‎17:01:12 (вроде бы последняя версия)
Валится так же как и раньше. Поправить 1 символ, не жадничайте
Из релиза в релиз идет ошибка при обработке начислений распределенных по группам составов затрат
Oшибка N 12 Переменная 'WRKI' не найдена.
...
PROCEDURE AR_MEDMONSAL.GET_COST
в процедуре

а должно быть

Получил ответ от parusbalance. При вводе данных через CTRL+V в ячейку отчет разбирает и располагает по строкам и столбцам только числовые данные, а также строковые, НО если к показателю привязан словарь, т.е. набор данных строго ограничен. Скопировать несколько строк с произвольной текстовой информацией (то, что я пытался сделать) на данный момент нельзя.
В очередной раз озадачился вопросом. Масштабный отчет строк на 1000 привел в ужас пользователей. При обратной связи некоторые делились (ложными?) воспоминаниями как буквально в прошлом месяце копировали и вставляли диапазонами из Excel в отчет сводов. А сейчас вдруг как раз когда надо - не работает.

Пробовал в разных комбинациях нажимать кнопки CTRL+C CTRL+V.
Максимум что получилось, скопировать диапазон, а ставить текст с табуляциями в 1 ячейку
Встроенный механизм копирования кусков отчета (Копировать в буфер, Вставить из буфера) в другие места отчета работает, хотя и медленно. Но это совсем не то, что нужно

Скрипты для загрузки отчета из Excel тоже не вариант, хотя и пробовал.

Может есть волшебная комбинация модели/версии браузера и Excel которые должны использоваться на сервере/клиенте?
Или правильный релиз.. у меня пока май 2020.

Озадачил parusbalance@gmail.com. Пока не получилось решить, хотя утверждают, должно работать
Решил спросить у сообщества

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

периодически вылезает эта ошибка. лечим в основном сменой браузера. Opera в этом вопросе помогает. Даже без сжатого режима.
KMS wrote:электронные больничные в формате 1,0 не грузятся, а их куча. Кто и как выходит из ситуации?

немного подождать (как мин. до появления записки с релиза 2020.12). потом копать процедуру загрузки
KRIS wrote:А что слышно по формату 1.7.7 ? Если верить http://docs.fss.ru/ c 15.12.2020 надо применять.


дадут пожить с форматом 1.7.6 пару месяцев, а вот
электронные Б/Л уже перестали грузиться в формате 1.0
 
Индекс форума » Профиль для CYMEPKU » Сообщения, отправленные пользователем CYMEPKU
Перейти: