Проекты и их характеристики


[ Пpишедшие ответы ] /www.hdru.com/wwwboard/faq.htm">Help ]

Posted by Рустем Мухаметшин on October 30, 1998 at 00:55:03:

In Reply to: Re: Планы выпуска новой версии posted by Аpкадий Водяник on October 29, 1998 at 20:14:12:

Общую информацию о моих проектах на ФБП Вы можете узнать на моем узле

Чистопольнефтепродукт: обычный Pentium200 256DIMM, Windows 95, ~4000 операций в месяц (~45000-50000 в год)
ТРО ВОИ: PentiumII233 128DIMM, Windows NT, ~2000 операций в месяц
Локальные сети Windows.
Клиентские части весьма разношерстны, хотя по моему сейчас уже все допускают установку хотябы Windows 3.11 Тем не менее большинство операторов на DOS клиенте (Исключение ТатНефтепродукт, он планируется исключительно под Windows клиент)

В настройках активным образом используются факты и экстрапараметры (обычные параметры отмерли, хотя они и экономней в смысле памяти).
Экстрапараметры: Удобный инструмент, но потребляет черезчур много памяти (по всей видимости под индекс закладывается фиксированный буфер ~128 байт) при использование на больших справочниках и документах. ЗАчастую индексы занимают памяти гораздо больше самих экстрапараметров.
Факты: Ну без них вообще никуда. Никогда не пользуюсь оператором total (Это самоубийство, к примеру оборотная товарная ведомость с ипользованием total будет работать от 15 и более минут). Всегда применяю однопроходный по фактам алгоритм с заполнением таблиц %

В настройке чистополя применяются достаточно сложные алгоритмы. В этой связи хочется отметить необходимость писать в нескольких ф/к достаточно объемные и одинаковые блоки кода в виду отсутствия подпрограмм общих для всех ф/к. К примеру в Чистополе применяются "красные остатки", это когда своего товара фактически нет, но путем некоторого недокументального заимствования он есть, а потом возвращается. Это общая проблема по крайней мере на предприятиях нефтеобеспечения Татарстана. По другому ее в виду множества причин решить нельзя. Так вот, привожу краткую идею алгоритма расхода товаров.
По количеству производим пересчет по необходимости литры-кг, кг-литры и определяем базовую еденицу измерения на конкретном складе(субсчете). Определяем остаток и перерасход. Определяем черные себестоимость, ндс и нгсм (на каждом товаре учитываются не только кол-во и себестоимость, но и суммы приходящегося ндс и нгсм). Определяем установленные красные цены отпуска себестоимостио, ндс, нгсм. Прописываем по необходимости сообщения об ошибках. Ни вкоем случае не допускаем деления на ноль, сложение строки с числом и прочие вещи которые могут повлечь ошибку в прошлом (раньше это было бы просто катастрофой:). Прописываем соответствующие изменения в экстрапараметрах и фактах (остатки храняться в экстрапараметрах, на фактах медленно работает) по черному и соответсвющему ему черному складу.
Этот алгоитм универсален и работает везде (41, 10, 12, 01, 04, 08, ...). Естественно что здесь достаточное кол-во как входных так и исходящих переменных, что делает необходимым ставить перед таким ф/к один или несколько ф/к устанавливающих эти переменные.
Подобной, или даже более высокой сложности алгоитмы расчета по отгрузке и получениям ТМЦ по счетам/фактурам. Он автоматически отслеживает оплаты (оператор все ставит на предоплату, программа распределяет ее в хронопорядке) и получения строи записи в книгах покупок и продаж и делает проводки по 19 счету

К сожалению, существущие ограничения на дерево операций весьма сильно сковывало руки. Дерево операций становилось менее структуризированным и некоторые вещи вообще не возможны.
К примеру большая проблема - справочники и их последовательности показа (зачастую в листьях дерева они занимают 3-5 строк). Если использовать ветвь вопрос, то в операции кроме замысловатого кода ничего не увидишь, кроме того о многострочности и не мечтай, а в ДОС клиенте нельзя узнать что было выбрано в предидущей ветви-вопросе. Если используешь @, то код должен присутсвовать в плане счетов и именно на данном счете, что сильно ограничивает. Сейчас например я думаю над проблемой партионного учета, нужно регистрировать партии товара - где (в плане счетов? - упаси бог). Сейчас найден выход, но он коряв (мягко говоря). Необходима в идеале последовательность: Склад-Товар-Партия, если призадуматься то в существующей технологии найдется масса проблем с этим (по крайней мере Товар-Партия исключается на Партия-Товар, что уже плохо, да и с многострочностью сложности).

Буду рад, если кто нибудь откликнется и поделиться своими проблемами в Финансах без проблем :)


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