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

Добро пожаловать, Гость. Пожалуйста, выберите:
Вход || Регистрация.
16.12.18 в 22:26:59


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

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

Работа с ФБП через браузер:
Настройка для лечебных учреждений, оказывающих медицинские услуги:
На форуме...
http://vasoft.ru

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

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






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

   Учет бюджетного предприятия. Украина.
« Нет темы | Следующая Тема »
Страниц: 1  Ответить | Уведомлять | Послать Тему | Печатать
   Автор  Тема: Учет бюджетного предприятия. Украина.  (Прочитано 3228 раз)
Boris, Kiev.
Moderator

*****



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

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

Сообщений: 827
Учет бюджетного предприятия. Украина.
« В: 31.10.17 в 10:35:40 »
Цитировать | Править

Добрый день!
 
Если кто-то озабочен переходом на новый план счетов в бюджетных организациях на Украине, то откликнетесь, пожалуйста.
 
Если кто порешал эти вопросы, то интересно познакомиться с решением.
 
Зарегистрирован
Boris, Kiev.
Moderator

*****



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

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

Сообщений: 827
Re: Учет бюджетного предприятия. Украина.
« Ответить #1 В: 30.01.18 в 09:44:58 »
Цитировать | Править

Законодатели бюджетного учета на Украине внедрили в жизнь совершенно новый план бухгалтерского учета, не без методических огрех по проводкам, но сегодня не об этом. Сегодня о самом плане и методе трансформации.
Он трехуровневый. Привожу фрагмент его описания:
 
Клас 1. Нефiнансовi активи
...
Рахунок 13 <Капiтальнi Iнвестицiї>
1311 (1321) <Капiтальнi Iнвестицiї в основнi засоби>;
 
 1312 (1322) <Капiтальнi Iнвестицiї в Iншi необоротнi матерiальнi активи>;
 
 1313 (1323) <Капiтальнi Iнвестицiї в нематерiальнi активи>;
 
 1314 (1325) <Капiтальнi Iнвестицiї в довгостроковi бiологiчнi активи>;
 
 1324 <Капiтальнi Iнвестицiї в необоротнi активи спецпризначення>.
 
Рахунок 14 <Знос (амортизацiя) необоротних активiв>
1411 (1421) <Знос основних засобiв>;
 
 1412 (1422) <Знос Iнших необоротних матерiальних активiв>;
 
 1413 (1423) <Накопичена амортизацiя нематерiальних активiв>;
 
 1414 (1424) <Знос Iнвестицiйної нерухомостi>;
 
 1415 (1425) <Накопичена амортизацiя довгострокових бiологiчних активiв>.
 
      Этот фрагмент объясняет, что «революция» существенна и к ней как-то надо приспособиться.
 
Т.к. это уже не первый эпизод в моей ФБП-истории под девизом «.. до основанья, а затем…», то в этот раз склонился к универсальному решению на перспективу дальнейших революций в этом вопросе, которое построил на одном простом постулате:
 
      - все объекты любого учета представляют собой элементы списков, к этим  спискам «вяжутся» все атрибуты, соответствующие требованиям учета таких объектов.  
 
Исходя из этого, наш старый добрый план со всеми прижившимися списками продолжит своё существование в прежнем виде и львиная доля ф-к с проводками и дерево останется без глобальных перестроек. Будем называть наш старый добрый план - Рабочим Планом(РП). В случае появления на горизонте принципиально новых объектов учета мы будем вынуждены родить в РП соответствующие им элементы и родить требуемые типовые операции.
Понятно, что все балансовые счета РП с остатками и обротами должны найти своё соответствие в новом плане, поэтому первой задачей трансформации является создание формы по установке этого соответствия.
Новый план описан в текством файле и выступает источником в алгоритме трансформации и может меняться разными способами. Главное поддерживать структурный принцип записей.
 Текущей особенностью стало то, что методисты решили разделить тематически субсчета старых счетов на разные счета новых счетов, то пришлось усложнить эту форму возможностью работы с группами с.с.. Благо, в бюджете военной тематики остаются существовать так называемые службы, которые находят своё отражение в ведущих приставках(пометках) в полях наименований с.с. и которые соответствуют этому тематическому разделению, поэтому требуемое разнесение было реализовано на этих пометках. Для окончательного понимания приведу пример:
Субсчета 221-го счета «МБП» разнесли на новые:
18124 – МШП;
1513      - Строительные материалы.
В полях наименований в бюджете повелось ставить ведущие пометки, которые отражают отнесение объекта к службе, выглядит это так:
03* Черенки [шт]
02* Орденские планки [шт]
Вот эти ведущие пометки(03*, 02*) и стали аргументами к автоматическому отнесению с.с. к разным счетам нового плана. 03* к 1513, 02* к 18124.
 
Второй задачей стало написание универсальной формы навигации по новому плану и оборотной ведомости в любом разрезе этой навигации. Для переходного периода решил объединить в одной форме два режима(старая и новая навигация). Попутно добил старую мечту о беспроблемной актуализации разворота плана в ветвях-вопросах при вводе новых операций(наследовал последний разворот пользователя, это было) и  перебивке имеющихся(разворот должен соответствовать текущему объекту в контексте операции!!!).
Третьей задачей стала перепись системных форм(аналог формы __SYS05 «съел» __SYS06, т.к. степеней укрупнения-детализации стало больше и реализовал их в одной и той же форме).
Четвёртая задача – модификация «лицевых» отчетных форм. Главную книгу закончил с переходами к системным до операции. Вот на этой стадии и описываю эту эпопею.
 Работы конечно ещё достаточно, но греет одно, что попутно вставляю суперскорострельный универсальный экспорт в | .xls | .doc | .htm.
 
Таким макаром получил достаточно гибкий функционал по манипулированию представлением существующими объектами ФБП учёта.
Вообщем, ещё раз подтвердилась народная или солдатская мудрость «Нас того, а мы крепчаем».
Если кто-либо творил что-то подобное, прошу, распишите аналогично. Интересно.
Кто видит плюсы или минусы такого подхода, то также «милости прошу», пишите.
« Изменён в : 30.01.18 в 12:23:19 пользователем: Boris, Kiev. » Зарегистрирован
Alexander_Kiev

*****





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

Сообщений: 661
Re: Учет бюджетного предприятия. Украина.
« Ответить #2 В: 26.05.18 в 14:25:39 »
Цитировать | Править

on 30.01.18 в 09:44:58, Boris, Kiev. wrote:

 Работы конечно ещё достаточно, но греет одно, что попутно вставляю суперскорострельный универсальный экспорт в | .xls | .doc | .htm.

Поделись результатом скорострельности формирования файлов *.xls. Меня, таблицы с тысячами строк давно начали напрягать. А как начал раскрашивать, еще грустнее.
Сколько получается тысяч ячеек в сек?
« Изменён в : 26.05.18 в 14:26:59 пользователем: Alexander_Kiev » Зарегистрирован

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

*****



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

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

Сообщений: 827
Re: Учет бюджетного предприятия. Украина.
« Ответить #3 В: 26.05.18 в 19:59:44 »
Цитировать | Править

Приветствую Саня!, вот уж не ожидал, что ты здесь появишься.
 
Читни здесь: http://hdru.com/cgi-bin/pp2/YaBB.cgi?board=errors;action=display;num=146 3636010;start=5#5
 
чтобы не повторяться.
За ним есть обсуждение с мельчайшими подробностями.
 
Мало кто из настройщиков оценил(пока только mine-R), остальные - скорее не поняли или им это даром не надо.
 
О главном твоем вопросе - не мерял, т.к. мерять нечего - мгновенно. Сервер - "выплюнул", клиент - перенаправил, всё.
« Изменён в : 26.05.18 в 20:03:11 пользователем: Boris, Kiev. » Зарегистрирован
Alexander_Kiev

*****





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

Сообщений: 661
Re: Учет бюджетного предприятия. Украина.
« Ответить #4 В: 28.05.18 в 14:17:55 »
Цитировать | Править

on 26.05.18 в 19:59:44, Boris, Kiev. wrote:

О главном твоем вопросе - не мерял, т.к. мерять нечего - мгновенно. Сервер - "выплюнул", клиент - перенаправил, всё.

Да я тоже раньше не замечал, а вот пару отчетов аля 1 Цэ на тысячи строк и полтора десятка колонок когда запустил, думал система упала. Пришлось и прогресс-бар устанавливать и отдельно еще и предупреждать если по прогнозу более 10 сек. Замерил - 2160 ячеек/с. Открывается практически так же. Юзвери привыкли к высокой реактивности, отчетный период ставят январь-декабрь и как зашарашат отчет за 8 месяцев и ждут десятками секунд.  
« Изменён в : 28.05.18 в 14:21:43 пользователем: Alexander_Kiev » Зарегистрирован

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

*****



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

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

Сообщений: 827
Re: Учет бюджетного предприятия. Украина.
« Ответить #5 В: 29.05.18 в 13:38:16 »
Цитировать | Править

on 28.05.18 в 14:17:55, Alexander_Kiev wrote:

Да я тоже раньше не замечал, а вот пару отчетов аля 1 Цэ на тысячи строк и полтора десятка колонок когда запустил,

ты на ФБП запускаешь?
 
Производительность нашего сервера по генерации *.out ты знаешь. Колонки, строчки, без разницы, мегабайты текстовых htm-строк клепаются весьма шустро.
Зарегистрирован
Alexander_Kiev

*****





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

Сообщений: 661
Re: Учет бюджетного предприятия. Украина.
« Ответить #6 В: 29.05.18 в 19:37:07 »
Цитировать | Править

on 29.05.18 в 13:38:16, Boris, Kiev. wrote:

ты на ФБП запускаешь?

Я запускаю на библиотеке java. Это отдельный продукт. Не думаю что он слабо оптимизирован, и просто хотел сравнить. Время записи в текстовый файл здесь ни при чем, львиная доля времени уходит на форматирование ячеек.
Можно просто сформировать файл тысяч на 20 ячеек и засечь по секундомеру. У себя я так и сделал, восемь с лишним тысяч строк, 11 колонок. В итоге 42 сек. Файл всего 2.8 метра, открывается тоже не хило 40 сек.
 
« Изменён в : 29.05.18 в 19:43:21 пользователем: Alexander_Kiev » Зарегистрирован

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

*****



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

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

Сообщений: 827
Re: Учет бюджетного предприятия. Украина.
« Ответить #7 В: 14.06.18 в 16:51:00 »
Цитировать | Править

on 29.05.18 в 19:37:07, Alexander_Kiev wrote:

Я запускаю на библиотеке java. Это отдельный продукт. Не думаю что он слабо оптимизирован, и просто хотел сравнить. Время записи в текстовый файл здесь ни при чем, львиная доля времени уходит на форматирование ячеек.
Можно просто сформировать файл тысяч на 20 ячеек и засечь по секундомеру. У себя я так и сделал, восемь с лишним тысяч строк, 11 колонок. В итоге 42 сек. Файл всего 2.8 метра, открывается тоже не хило 40 сек.
 

 
вот запись лога
 
C> 16:27:26  14.06.2018
AD··620A2L@@·R FQ-ORFBE ·3·СТРОИМ ОТЧЕТ в .xls-формате·
S> 3.61 6863716
 
Напомню тебе наш формат лога
 
S> 3.61 6863716
Это 3.61 секунды и 6.8Мb текстовый OUT готов.
 
Эксель открывает за ~5секунд таблицу со столбцами от A до S  и всего 4485 строк.
 
Т.е. 19*4485=85215 ячеек
Зарегистрирован
Alexander_Kiev

*****





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

Сообщений: 661
Re: Учет бюджетного предприятия. Украина.
« Ответить #8 В: 05.08.18 в 12:41:56 »
Цитировать | Править

on 14.06.18 в 16:51:00, Boris, Kiev. wrote:

 
вот запись лога
 
C> 16:27:26  14.06.2018
AD··620A2L@@·R FQ-ORFBE ·3·СТРОИМ ОТЧЕТ в .xls-формате·
S> 3.61 6863716
 
... Эксель открывает за ~5секунд таблицу со столбцами от A до S  и всего 4485 строк.

Ну в общем время открытия файла соизмеримо с временем формирования, значится интерпретатор JVM не сильно проигрывает.
Намедни я начал интересоваться СУБД в частности MySQL. Закатал в таблицу то что мы называем лентой фактов и сравнил эффективность сканирования. Так результат практически одинаковый. При сим надо иметь в виду, что сама процедура добавления записи в таблицу десятикратно проигрывает добавлению операции относительно идеологии Финансов. Процедура именуемая построением баланса, тут и близко ничего соизмеримого. СУБД проигрывают уже в десятки тысяч раз, правда при условии отказа от того что было названо "быстрыми фактами" в Финансах. Я ими никогда и не пользовался.  
СУБД меня заинтересовали в контексте организации связанных данных в структуре. Сама организация связанных данных не напрягает, а вот в случае прецедентов с удалением или редакцией связанных данных начинается геморрой. В СУБД это решено на базовом уровне. Ну и в вопросе организации учета с автоматической актуализацией текущего состояния данных, при вмешательстве в прошлое, - СУБД соответственно, по прежнему не конкурент.
« Изменён в : 05.08.18 в 13:04:34 пользователем: Alexander_Kiev » Зарегистрирован

С уважением,
Александр.
Страниц: 1  Ответить | Уведомлять | Послать Тему | Печатать

« Нет темы | Следующая Тема »

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