Автор |
Тема: CAS.RUL (Прочитано 1400 раз) |
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
Уважаемые, может кто уже смастерил форму, анализирующую дерево видов?
Требуется, корректно, решить проблему авточистки плана счетов, объекты которого указаны явным образом в дереве.
Директива T или функция [tf.. не дают доступа к записям проводок, поэтому придётся разбираться с самим CAS.RUL
|
|
 Зарегистрирован |
|
|
|
Vladimir
Я люблю этот Форум!
Просмотреть Профиль | WWW |
Сообщений: 264
|
on 08.07.16 в 11:34:22, Boris, Kiev. wrote:Уважаемые, может кто уже смастерил форму, анализирующую дерево видов?
авточистки плана счетов, объекты которого указаны явным образом в дереве.
|
|
Указаны или НЕ указаны?
|
|
Зарегистрирован |
С уважением,
Владимир
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
on 10.07.16 в 03:56:20, Vladimir wrote:
Конечно, УКАЗАНЫ.
Похоже, что изложил не достаточно понятно.
Согласен, что нужно было чуть уже, но понятнее:
"Требуется, корректно, решить проблему авточистки плана счетов, объекты которого могут быть указаны явным образом в дереве. "
типа:
301001 @311 (s)
Считал и считаю правилом хорошего тона творений дерева в ФБП то, что в дереве не должно быть ни одного явного обращения к балансовым счетам и тем более к их с.с.
Однако, в текучке, пользователи прибегают к тривиальным решениям и плодят в дереве скороспелые типы операций с группами явных проводок, т.е. опирающихся на объекты плана, как счета, так и с.с. Со временем, дерево пухнет такими скороспелками и самим пользователям становится не комфортно от объема своих «типовых». Доходит до того, что с.с. использованные в таких проводках в следующие годы попадают в список объектов к удалению(остаток 0, обротов 0), и здесь возникает крах, так, как мои формы по авточистке ACNT.A3P и EXTRA.B не проверяли до сих пор признак явного использования таких объектов в дереве. Вот этот недостаток и нужно преодолеть. Разобраться со структурой CAS.RUL реально, но морочливо, вот и обратился. Подумал, что, может уже кто-нибудь решил этот вопрос в форме на клиенте и готов помочь, но похоже, что никто до сих пор не обременял себя такой задачей, да и лето на дворе, поэтому через пару дней придёться самому завершить эту веточку, т.к. подопечные долго ждать не могут.
|
| « Изменён в : 10.07.16 в 09:54:47 пользователем: Boris, Kiev. » |
Зарегистрирован |
|
|
|
mine-R
compact & flexible rulezzz
Просмотреть Профиль |
Сообщений: 150
|
Подобное решалось как правило "малой кровью". Чтобы обезопасить счета, в алгоритмах очистки предусматривалось запоминание счета-родителя и инструкция "не трогать тех, чей предок План", соответственно для субсчетов - "не трогать тех, чей предок тот-то..".
К анализу дерева это конечно отношения не имеет.
Перспектива же анализа бинарного cas.rul, загруженного транзитом через loadbin побайтно в массив %, на предмет присутствия субсчетов, как-то априори ввергает в уныние. Ибо предполагает абсолютно любую встретившуюся буквенно-цифровую (+допустимые в обозначении с/счетов символы) последовательность, оканчивающуюся пробелом, проверять по [ex..] на присутствие в плане.
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
on 11.07.16 в 18:52:21, mine-R wrote:
Перспектива же анализа бинарного cas.rul, загруженного транзитом через loadbin побайтно в массив %, на предмет присутствия субсчетов, как-то априори ввергает в уныние. Ибо предполагает абсолютно любую встретившуюся буквенно-цифровую (+допустимые в обозначении с/счетов символы) последовательность, оканчивающуюся пробелом, проверять по [ex..] на присутствие в плане. |
|
Вы сгущаете краски.
Т.к. Аркадий опубликовал в руководстве к локалу структуру cas.rul, то эта задача упрощается.
Вот моё решение в такой форме, в которой изначально принял бы помощь коллеги.
Надеюсь, что она окажется полезной не только для меня.
http://hdru.com/russian/RPT_FOR_ALL-160712.zip
Замечу, что профиллирование и в этот раз было задействовано. Может, рванёте сделать более скорострельную форму и решить вопрос редакции дерева?
Буду очень рад.
|
|
Зарегистрирован |
|
|
|
mine-R
compact & flexible rulezzz
Просмотреть Профиль |
Сообщений: 150
|
Интересные получились решения. Таких задач как у Вас, пока не возникало, но помимо всего прочего, такие формы однозначно полезны если нужно получить дополнительное (к директиве Т) представление о дереве и его структуре, с сетевого клиента.
on 12.07.16 в 19:33:07, Boris, Kiev. wrote: Может, рванёте сделать более скорострельную форму и решить вопрос редакции дерева?
Буду очень рад. |
|
Скорострельность форм совсем не создаёт дискомфорта, да и не является она принципиальной в таких формах. Это всё-таки инструментарий администраторов ( кстати, в плане выбора имени подписи админа форма слегка по-диктаторски себя ведёт  ) или уж очень-очень продвинутых пользователей.
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
Согласен, просто – это уже AD-привычка.)
Согласитесь, что при наличии такой формы в арсенале администратора, помимо обновления признаков объектов плана, ему уже будет леньки открывать локал, в случае поиска соответствующего ФК и восстановления в памяти всех переменных в ветвях. Возможность прямого перехода к соответствующему ФК – это хорошая экономия времени для настройщика.
Осталось прикрутить редакцию дерева из этой формы и про локал можно будет забыть в этой части.
Скорее всего доделаю это, т.к. в форме на клиенте откроется больше возможностей с предупреждениями и запретами, которые требуют актуального состояния базы. Ведь загрузить виндовый локал на реальной базе многих заказчиков не представляется возможным из-за объемов баз, а редакция дерева без текущих данных, для молодых настройщиков напоминает проход по минному полю. Поэтому возможность редакции дерева из этой формы должна быть весьма полезной многим настройщикам, хотя если до сих пор обходились, то …
Вообщем для полноты картины – надо сделать!
Как подкатит, так и сделаем.)
|
|
Зарегистрирован |
|
|
|
mine-R
compact & flexible rulezzz
Просмотреть Профиль |
Сообщений: 150
|
Тут однозначно согласен - если в форму добавится механизм редактирования дерева, появится инструмент, универсальный и для x32 и для x64 ОС. Хотя в голове не укладывается пока, как это может быть реализовано средствами rpt-формы.
А про локал всё-равно забудется ещё не скоро. По крайней мере теми, у кого к локалу сформировалась привычка. Из-за удобной возможности "резать-клеить" и моментального обновления изменений в дерево по F2. Ведь одним из возможных минусов может стать необходимость перезагрузки сервера после каждого изменения в дерево. А представьте, что администратор допустил опечатку и сервер не загрузился - тут уже возврат к *.bak необходим..
Думаю, все подобные "подводные камни" Вы уже в голове прокрутили, и намёки на идеи реализации подобного средствами rpt-формы уже какие-то есть.
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
on 16.07.16 в 12:17:50, mine-R wrote:| Ведь одним из возможных минусов может стать необходимость перезагрузки сервера после каждого изменения в дерево. |
|
Здесь не соглашусь и настаиваю на обратном.
Выше, об этом уже сказал и повторюсь, что как раз возможность редакции из формы, которая будет отрабатывать на реально загруженной базе будет выигрывать от текущего варианта работы с деревом в локале, т.к. локал поднять реальную базу большинства предприятий не в состоянии и отразить все огрехи правок дерева не может оперативно, а форма – наоборот, будет запросто говорить какой фрагмент дерева можно править, а какой категорически «низзя». Думаю, что подробнее Вам расписывать уже не нужно. Попробую сотворить такую форму, что вероятность аварийной ситуации загрузки сервера на живой базе на поправленном дереве сведётся к 0, конечно за исключением творчества настройщика в новоиспеченных ФК. Здесь конечно сервер мог бы расстараться и поддержать работу в двух режимах, первый – как сейчас(быстро без лишних системных проверок) и второй с системными проверками(медленнее, но без фатальных финалов и соответствующими комментариями по неудавшимся ФК).
Спасибо за понимание и оценку перспективы такой формы.
|
|
Зарегистрирован |
|
|
|
|
|
