Проблемы проекта для бюджетной организации



Posted by Алексей Смирнов, Алла Козорез (212.109.39.111) on February 26, 2001 at 11:49:01:

В процессе внедрения крупного сетевого проекта автоматизации
бухгалтерии бюджетной организации (Винницкого государственнного
аграрного университета) возник ряд вопросов, требующих помощи.
Некоторые характеристики проекта.
В настоящее время функционируют следующие взаимосвязанные
подзадачи: БАНК (6 счетов), КАССА, ЦЕЛЕВОЕ ИСПОЛЬЗОВАНИЕ
БЮДЖЕТНЫХ СРЕДСТВ, МАТЕРИАЛЫ, ДЕБИТОРЫ-КРЕДИТОРЫ, ОПЛАТА ЗА
ОБЩЕЖИТИЕ И ОБУЧЕНИЕ, ОСНОВНЫЕ СРЕДСТВА. Общее количество
субсчетов - около 17000, в среднем за месяц 3000-3500 операций
с 5-6 проводками или 2-3 фактами к каждой.

Профиль для RAM 64M, Celeron-466, Сервер 3.14:

Финансы без проблем:Профилер сообщает:


Расходы времени на пересчет состояния сервера:

всего,мс %
-------------------------------------------------
Чтение файлов операций (*.f3p): 476 0.7
Анализ фраз операций: 525 0.7
Выполнение проводок: 13121 18.7 #####
Выполнение файлов-коэффициентов: 7292 10.4 ###
Вычисление выражений в дереве: 1461 2.1
Дескрипторы первичных документов: 0 0.0
Создание первичных документов: 0 0.0
Инициализация внутренних таблиц: 47263 67.4 ####################
Индикация на мнемосхеме: 18 0.0
-------------------------------------------------
Итого: 70156 100.0

За эти 70156 мс было пересчитано 2972 операций.
Средняя скорость пересчета состояния сервера: 42 оп/с

Расходы времени на выполнение файлов-коэффициентов:
-------------------------------------------------
Файл всего,мс разы мс/раз абс% отн%
-------------------------------------------------
PKO 3150 887 3.6 4.5 43.2 ############
GU_TAX 700 141 5.0 1.0 9.6 ##
RKO 679 573 1.2 1.0 9.3 ##
G_TAX1 599 106 5.7 0.9 8.2 ##
G_TAX 516 142 3.6 0.7 7.1 ##
INPUT1 428 46 9.3 0.6 5.9 #
ZALPIL 411 307 1.3 0.6 5.6 #
ST_TAX 327 524 0.6 0.5 4.5 #
INPUT_0 262 1 262.0 0.4 3.6 #
PKO1 100 887 0.1 0.1 1.4
RKO1 66 573 0.1 0.1 0.9
G_TAX2 35 114 0.3 0.0 0.5
STUDY_BG 10 318 0.0 0.0 0.1
ST_TAX- 2 4 ~ ~ ~
-------------------------------------------------


Расходы времени на выполнение команд в файлах-коэффициентах:
----------------------------------------------------
Команда всего,мс разы мкс/раз абс% отн%
----------------------------------------------------
folio-177 3274 1602 2043.7 4.7 44.9 #############
fact 2610 4188 623.2 3.7 35.8 ##########
[SET] 506 10637 47.6 0.7 6.9 ##
[PLUS] 336 3463 97.0 0.5 4.6 #
$$ 119 7178 16.6 0.2 1.6
set var 113 35890 3.1 0.2 1.5
[N1] 79 7895 10.0 0.1 1.1
push var 50 64653 0.8 0.1 0.7
[GET] 39 8508 4.6 0.1 0.5
[INTERNAL] 27 22608 1.2 0.0 0.4
@a 26 5394 4.8 0.0 0.4
[DA] 18 902 20.0 0.0 0.2
[CO] 17 2967 5.7 0.0 0.2
.=0, goto 13 18201 0.7 0.0 0.2
- 11 2140 5.1 0.0 0.2
push account 10 11504 0.9 0.0 0.1
[USER] 7 47 ~ ~ ~
push double 6 42698 ~ ~ ~
nop 5 6208 ~ ~ ~
a=L 5 47 ~ ~ ~
[STRIP] 4 10083 ~ ~ ~
~ 3 7355 ~ ~ ~
+ 2 8184 ~ ~ ~
= 2 15623 ~ ~ ~
& 1 861 ~ ~ ~
push string 1 33093 ~ ~ ~
[N2] 1 94 ~ ~ ~
if ~ 94 ~ ~ ~
nextif ~ 47 ~ ~ ~
* ~ 1184 ~ ~ ~
/ ~ 765 ~ ~ ~
< ~ 221 ~ ~ ~
> ~ 2920 ~ ~ ~
unar minus ~ 1679 ~ ~ ~
goto ~ 3364 ~ ~ ~
stop ~ 117 ~ ~ ~
pop stack ~ 5604 ~ ~ ~
| ~ 106 ~ ~ ~
a=b ~ 245 ~ ~ ~
a=r ~ 683 ~ ~ ~
a+L ~ 855 ~ ~ ~
[cp a,r1,r2] ~ 4213 ~ ~ ~
a==r ~ 451 ~ ~ ~
#a ~ 6366 ~ ~ ~
*a ~ 787 ~ ~ ~
[EP] ~ 632 ~ ~ ~
[CE] ~ 3269 ~ ~ ~
[RO] ~ 348 ~ ~ ~
[TR] ~ 348 ~ ~ ~
[SN] ~ 126 ~ ~ ~
[VL] ~ 2706 ~ ~ ~
[TYPE] ~ 8637 ~ ~ ~
[INTSN] ~ 3213 ~ ~ ~
[LENGTH] ~ 2920 ~ ~ ~
[STAMP] ~ 4188 ~ ~ ~

-----------------------------------------------------

В реальности: RAM 128M, Celeron-466, Сервер 3.15, Win'95,
клиентская программа наша.

Теперь вопросы.

1)
Реально операции вводятся с некоторым отставанием от текущей даты.
В промежутке от вносимой операции до текущей даты обязательно есть хотя
бы один null (например, хвост от удаленной операции). Результат -
пересбивка баланса с задержкой от 20 до 30 с. Даже 2 оператора в таком
случае проблематичны.
Пример.
Сегодня 26.02.2001. Введена некая операция (первая за этот день).
Теперь операцию удаляем и вводим новую, последнюю по порядку от
25.01.2001.
На диаграмме сервера четко виден процесс пересбивки. Нужен ли он,
если операции носят служебный характер (null) ?..

2)
В работе оператора неизбежны ошибки. Автонумерацию мы реализовали
своими силами. А вот защита от неправильного ввода наименования
кажется неразрешимой. Необходима возможность удаления и корректировки
наименований .a3p.
Есть у нас порядка 17000 субсчетов (ОФ, материалы, МБП, студенты и
т.д.). МБП в кол-ве 1000 - списаны в середине года, часть студентов
отчислена, большая часть в конце года - выпускники. Значит теперь
выходим в монопольную версию и начинаем F8 и т.д. или запускаем свою
форму, которая будет анализировать каждый субсчет по десятку его
параметров, нужен он нам или нет. Кстати, монопольная версия возможна
до определенного момента, например, баланс с середины 2000 года в
ней построить уже невозможно.

3)
Существует подзадача автоматической нумерации документооборота.
Каким образом вставить требуемый номер в середине дня после удаления
операции для документа строгой отчетности, когда порядок операций
фиксируется и изменению не подлежит. Для этого необходимо удалить
все последующие операции в течение этого дня.
Пример.
Идут ПКО No 1, 2, 3, 4... ПКО No 2 удалили. Что теперь делать,
сортировать самому в отчетной форме ?.. Хорошо, если номера у нас
фиксируются в ветке-вопросе, но ведь для ПКО этот вариант не проходит
(введен, например, вообще неверный ордер, а после него еще порядка
300 -> после его удаления последующие должны быть перенумерованы).
При этом десяток пользователей, которые так или иначе должны видеть
операции друг друга и иметь возможность корректировки и удаления
-> запоминать номер нельзя.

Хотелось бы услышать также об ошибке в операторе [ir] (Доску не читал).

Алексей Смирнов, программист
Алла Козорез, бухгалтер-программист

фирма ПАЛЛАР Лтд., г.Винница


Пpишедшие ответы: