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



Posted by Анатолий Анимица (194.177.32.70) on February 26, 2001 at 15:41:03:

In Reply to: Проблемы проекта для бюджетной организации posted by Алексей Смирнов, Алла Козорез on February 26, 2001 at 11:49:01:

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


Не очень понял, что здесь крупного - вполне среднее предприятие с очень низкой активностью оборотов счетов: что такое 3500 операций по 5-6 проводок, это 21000 проводок в месяц? По 1 проводке в месяц на счет? Если это стипендия студентам, то проводка нужна одна в месяц на институт - деньги выданы для раздачи, одна в месяц - невыданные деньги возвращены на депонент, кому сколько надо - это короткий факт в 2..4 поля, из которого ведомости строятся, ну можно тем 3..5% студентов, которым не выдали деньги, запомнить депоненты - еще 1000 фактов. Не о чем говорить. Еще одно замечание - 2 миллисекунды на одну проводку - это, похоже, на 50% свопинг. Надо где-нибудь взять еще один DIMM 128 MB на 10 минут и посмотреть, что изменится.


Теперь вопросы.: 1): Реально операции вводятся с некоторым отставанием от текущей даты. Пересбивка баланса с задержкой от 20 до 30 с. Даже 2 оператора в таком случае проблематичны.

Месяц должен на таких объемах пересчитываться за три секунды! И это реальные результаты - в довольно сложной системе, нагруженной в операциях до предела - файл-коэффициент сотня строк от левого края экрана до правого - одна миллисекунда. Из них 600 микросекунд на 4-5 проводок. 200 микроскунд на news и 20 мкс на факт. Примерно так. То есть в боевой системе с 20000 операций в месяц можно упростить учет до скорости 2000..3000 операций в секунду и получить те же 5..7 секунд на месяц. На ПКП давно, с лета, и вполне успешно продается моя программка для замера статистик задержек - она может помочь в изучении обстановки с вводом данных.
Еще одно соображение. А кто сказал, что дата операции должна совпадать с датой проводки по ней? Существует технология, в которой ВСЕ операции пишутся ТОЛЬКО в реальной дате, а дату размещения содержат в одном из полей (ветви-вопросе). В этой технологии проблема пересчета состояния вообще не стоит. И можно иметь 200000 операций в месяц без всякого напряжения.

Пример. Сегодня 26.02.2001. Введена некая операция и т.д.


Пример не обсуждается из-за крайней простоты. Сервер проходит null за микросекунду, поэтому не о чем говорить. Удаление этих null и перепостроение файлов f3p займет больше времени и других ресурсов.

2) В работе оператора неизбежны ошибки. Автонумерацию мы реализовали своими силами. А вот защита от неправильного ввода наименования кажется неразрешимой. Необходима возможность удаления и корректировки
: наименований .a3p.

Но такая программа "удаления и корректировки" наименований есть! И она входит в комплект 2001R. Наименование заменяется на его обновление в extrd.dat и больше никто не увидит записанного в a3p, кроме привилегированного пользователя (в 2001R это S - системный администратор или он же и глабух под одним именем). Там нет еще режима "Hidden" - но не проблема встроить, только скажите, и тогда из 17000 субсчетов можно 15000 сделать невидимыми.

Есть у нас порядка 17000 субсчетов (ОФ, материалы, МБП, студенты и
: т.д.). МБП в кол-ве 1000 - списаны в середине года, часть студентов
: отчислена, большая часть в конце года - выпускники.

Hidden их - и нет ребенка-инвалида. Проводки к ним делаются, даже увидеть можно, а в списках вывод блокируется и время на них не тратится.

Кстати, монопольная версия возможна до определенного момента, например, баланс с середины 2000 года в ней построить уже невозможно.

В Ultra-32 невозможно??!

3) Существует подзадача автоматической нумерации документооборота. Каким образом вставить требуемый номер в середине дня после удаления операции для документа строгой отчетности, когда порядок операций фиксируется и изменению не подлежит.

Не существует такой подзадачи. По крайней мере в списке неразрешимых. В той же пресловутой 2001R на ветвях-нумераторах стоят формы (кстати, сервер 3.15 надо выбросить и заменить на 3.18, так как в ветвях нумерации используется кодирование номера как строки символов, а в серерах раньше 3.18 этого не сделаешь без опасности потери ведущих нулей в коде номера).


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

Вопиющая небрежность в бухучете или система класса Оруэлл-1984? Даже в этом случае есть решение. Например, зафиксируйте начальный номер документа дня и потом на целый день отдайте задачу полностью автоматическому нумератору. На следующий день то же самое и т.д.

При этом десяток пользователей, которые так или иначе должны видеть операции друг друга и иметь возможность корректировки и удаления -> запоминать номер нельзя.

Ничего не понял, но вопрос хороший. Это вопрос о блокировке повторного резервирования номера другим оператором, пока первый вводит его в клиенте, а сервер об этой радости ничего не знает. Я ее решил, эту задачу, пару лет назад - иногда ее приходится применять, когда, скажем, три-четыре рабочих места молотят счет-фактуры вслепую, не видя друг друга. Идея простейшая, как сибирский валенок. Тот же нумератор - в середине операции - еще до окончания ее ввода - записывает признак блокировки в extrd.dat ( я понятно излагаю?), и другой такой же нумератор, выдумав себе новый номер для оферты оператору, обнаружив, что кто-то такой же умный номер занял, сам выбирает следующий. Разумеется, если первый оператор откажется от своей гнусной затеи добить до конца операцию, номер повиснет в списке заблокированных. Для этого существует "время жизни блокировки" - если две или три минуты номер не нашел своего места в строю - он уничтожается и поступает в оборот обратно.


Хотелось бы услышать также об ошибке в операторе [ir]

КАКОЙ ОШИБКЕ?

Общее впечатление от вопроса.

1. Очень перспективная работа, только надо немножко поучить матчасть и фундаментальные основы как надо и как не надо программировать.
2. Стоимость железа сейчас в точности равна нулю. Даже Pentium III Xeon 2 Мб кэш не является чрезмерной затратой для конторы, где учитывается 10000 человек.
3. Все самоделки типа клиент-2000, если я правильно понимаю обстановку, только вредят делу. Вместо того, чтобы уделить внимание алгоритмам и их оптимизации, это уводит на тропу борьбы с особенностями интерфейса.
4. Я уже много раз писал, что программирование систем на платформе ФБП, к счастью, требует целостного системного подхода, когда "нажми на кнопки - выйдут бабки" не есть хороший стиль разработки. Или надо брать готовые системы (полуфабрикаты, настройки) и развивать их дальше. Или заказывать разработку у тех, кто умеет. Заодно научиться и дальше работать на более высоком уровне.


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