ФИНАНСЫ БЕЗ ПРОБЛЕМ(tm):
ПЕРЕГОВОРНЫЙ ПУНКТ II

Добро пожаловать, Гость. Пожалуйста, выберите:
Вход || Регистрация.
22.08.17 в 14:01:18


Наш сайт | Cтаpый форум (до 08.2003 года) | Интернет-магазин & Центр загрузок |
Главная | Помощь | Поиск | Участники | Вход | Регистрация
Модифицированный Клиент CLW32:
Из документации ...
На форуме...

Использование Клиента FCM:
1. Отчетный период и журнал операций.
2. Печать.
3. Экспорт.
4. Многострочная операция.
5. Редактирование многострочных операций.
http://www.fwp-client.com

Технический аудит настройки.
[Читать]

ФИНАНСЫ БЕЗ ПРОБЛЕМ (сетевая) и Opencart:
предлагаем:
1. Выгрузка новых покупателей из интернет-магазина в план счетов и сохранение информации в extrd.dat.
2. Выгрузка данных о заказанном товаре и сохранение в ФБП в журнале операций, номер заказа регистрируем в плане счетов как с.счет.
3. Українська локалізація.






   Финансы без пpоблем: Пеpеговоpный Пункт II
   Готовые pешения, ФБП и законодательство

   CAS.RUL
« Предыдущая Тема | Следующая Тема »
Страниц: 1  Ответить | Уведомлять | Послать Тему | Печатать
   Автор  Тема: CAS.RUL  (Прочитано 407 раз)
Boris, Kiev.
Moderator

*****



Адепт ФБП  с 1996г.

   
Просмотреть Профиль | E-мэйл

Сообщений: 809
CAS.RUL
« В: 08.07.16 в 11:34:22 »
Цитировать | Править

Уважаемые, может кто уже смастерил форму, анализирующую дерево видов?
 
Требуется, корректно, решить проблему авточистки плана счетов, объекты которого указаны явным образом в дереве.
 
Директива T или функция [tf.. не дают доступа к записям проводок, поэтому придётся разбираться с самим CAS.RUL
 
 
Зарегистрирован
Vladimir

***



Я люблю этот Форум!

   
Просмотреть Профиль | WWW |

Сообщений: 230
Re: CAS.RUL
« Ответить #1 В: 10.07.16 в 03:56:20 »
Цитировать | Править

on 08.07.16 в 11:34:22, Boris, Kiev. wrote:
Уважаемые, может кто уже смастерил форму, анализирующую дерево видов?
 
 авточистки плана счетов, объекты которого указаны явным образом в дереве.
 

 
Указаны или НЕ указаны?
Зарегистрирован

С уважением,
Владимир
Boris, Kiev.
Moderator

*****



Адепт ФБП  с 1996г.

   
Просмотреть Профиль | E-мэйл

Сообщений: 809
Re: CAS.RUL
« Ответить #2 В: 10.07.16 в 09:42:53 »
Цитировать | Править

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

   
Просмотреть Профиль |

Сообщений: 101
Re: CAS.RUL
« Ответить #3 В: 11.07.16 в 18:52:21 »
Цитировать | Править

Подобное решалось как правило "малой кровью". Чтобы обезопасить счета, в алгоритмах очистки предусматривалось запоминание счета-родителя и инструкция "не трогать тех, чей предок План", соответственно для субсчетов - "не трогать тех, чей предок тот-то..".  
 
К анализу дерева это конечно отношения не имеет.
 
Перспектива же анализа бинарного cas.rul, загруженного транзитом через loadbin побайтно в массив %, на предмет присутствия субсчетов, как-то априори ввергает в уныние. Ибо предполагает абсолютно любую встретившуюся буквенно-цифровую (+допустимые в обозначении с/счетов символы) последовательность, оканчивающуюся пробелом, проверять по [ex..] на присутствие в плане.
Зарегистрирован
Boris, Kiev.
Moderator

*****



Адепт ФБП  с 1996г.

   
Просмотреть Профиль | E-мэйл

Сообщений: 809
Re: CAS.RUL
« Ответить #4 В: 12.07.16 в 19:33:07 »
Цитировать | Править

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
 
Замечу, что профиллирование и в этот раз было задействовано. Может, рванёте сделать более скорострельную форму и решить вопрос редакции дерева?
Буду очень рад.
Зарегистрирован
Boris, Kiev.
Moderator

*****



Адепт ФБП  с 1996г.

   
Просмотреть Профиль | E-мэйл

Сообщений: 809
Re: CAS.RUL
« Ответить #5 В: 13.07.16 в 09:41:27 »
Цитировать | Править

Последняя форма более полезна будет для настройщиков, здесь добавил имена переменных в ветвях.
 
http://hdru.com/russian/RPT_FOR_ALL-160713.zip
Зарегистрирован
mine-R

***



compact & flexible rulezzz

   
Просмотреть Профиль |

Сообщений: 101
Re: CAS.RUL
« Ответить #6 В: 13.07.16 в 17:50:49 »
Цитировать | Править

Интересные получились решения. Таких задач как у Вас, пока не возникало, но помимо всего прочего, такие формы однозначно полезны если нужно получить дополнительное (к директиве Т) представление о дереве и его структуре, с сетевого клиента.
 
on 12.07.16 в 19:33:07, Boris, Kiev. wrote:
Может, рванёте сделать более скорострельную форму и решить вопрос редакции дерева?
Буду очень рад.

 
Скорострельность форм совсем не создаёт дискомфорта, да и не является она принципиальной в таких формах. Это всё-таки инструментарий администраторов ( кстати, в плане выбора имени подписи админа форма слегка по-диктаторски себя ведёт  Smiley ) или уж очень-очень продвинутых пользователей.
Зарегистрирован
Boris, Kiev.
Moderator

*****



Адепт ФБП  с 1996г.

   
Просмотреть Профиль | E-мэйл

Сообщений: 809
Re: CAS.RUL
« Ответить #7 В: 13.07.16 в 19:18:56 »
Цитировать | Править

Согласен, просто – это уже AD-привычка.)
 
Согласитесь, что при наличии такой формы в арсенале администратора, помимо обновления признаков объектов плана, ему уже будет леньки открывать локал, в случае поиска соответствующего ФК и восстановления в памяти всех переменных в ветвях. Возможность прямого перехода к соответствующему ФК – это хорошая экономия времени для настройщика.
Осталось прикрутить редакцию дерева из этой формы и про локал можно будет забыть в этой части.
Скорее всего доделаю это, т.к. в форме на клиенте откроется больше возможностей с предупреждениями и запретами, которые требуют актуального состояния базы. Ведь загрузить виндовый локал на реальной базе многих заказчиков не представляется возможным из-за объемов баз, а редакция дерева без текущих данных, для молодых настройщиков напоминает проход по минному полю. Поэтому возможность редакции дерева из этой формы должна быть весьма полезной многим настройщикам, хотя если до сих пор обходились, то …
Вообщем для полноты картины – надо сделать!
Как подкатит, так и сделаем.)
Зарегистрирован
mine-R

***



compact & flexible rulezzz

   
Просмотреть Профиль |

Сообщений: 101
Re: CAS.RUL
« Ответить #8 В: 16.07.16 в 12:17:50 »
Цитировать | Править

Тут однозначно согласен - если в форму добавится механизм редактирования дерева, появится инструмент, универсальный и для x32 и для x64 ОС. Хотя в голове не укладывается пока, как это может быть реализовано средствами rpt-формы.
 
А про локал всё-равно забудется ещё не скоро. По крайней мере теми, у кого к локалу сформировалась привычка. Из-за удобной возможности "резать-клеить" и моментального обновления изменений в дерево по F2. Ведь одним из возможных минусов может стать необходимость перезагрузки сервера после каждого изменения в дерево. А представьте, что администратор допустил опечатку и сервер не загрузился - тут уже возврат к *.bak необходим..
 
Думаю, все подобные "подводные камни" Вы уже в голове прокрутили, и намёки на идеи реализации подобного средствами rpt-формы уже какие-то есть.
Зарегистрирован
Boris, Kiev.
Moderator

*****



Адепт ФБП  с 1996г.

   
Просмотреть Профиль | E-мэйл

Сообщений: 809
Re: CAS.RUL
« Ответить #9 В: 17.07.16 в 10:42:48 »
Цитировать | Править

on 16.07.16 в 12:17:50, mine-R wrote:
Ведь одним из возможных минусов может стать необходимость перезагрузки сервера после каждого изменения в дерево.

 
Здесь не соглашусь и настаиваю на обратном.
Выше, об этом уже сказал и повторюсь, что как раз возможность редакции из формы, которая будет отрабатывать на реально загруженной базе будет выигрывать от текущего варианта работы с деревом в локале, т.к. локал поднять реальную базу большинства предприятий не в состоянии и отразить все огрехи правок дерева не может оперативно, а форма – наоборот, будет запросто говорить какой фрагмент дерева можно править, а какой категорически «низзя». Думаю, что подробнее Вам расписывать уже не нужно. Попробую сотворить такую форму, что вероятность  аварийной ситуации загрузки сервера на живой базе на поправленном дереве сведётся к 0, конечно за исключением творчества настройщика в новоиспеченных ФК. Здесь конечно сервер мог бы расстараться и поддержать работу в двух режимах, первый – как сейчас(быстро без лишних системных проверок) и второй с системными проверками(медленнее, но без фатальных финалов и соответствующими комментариями по неудавшимся ФК).
 
Спасибо за понимание и оценку перспективы такой формы.
 
Зарегистрирован
Страниц: 1  Ответить | Уведомлять | Послать Тему | Печатать

« Предыдущая Тема | Следующая Тема »

Powered by YaBB 1 Gold - SP 1.3.2!
Forum software copyright й 2000-2004 Yet another Bulletin Board