Шаг 2 - Предварительные замечания к структуре проекта

Начну с принципов, на которых мы построили нашу систему. Сразу предположилась некоторая документо-ориентированность. Что это значит? Мы подумали, что в основе любых хозяйственных действий лежат документы (это могут быть счета, счета-фактуры, платежные документы, накладные... ) все эти документы имеют строго определенную форму и, главное, унифицированное содержание, а при попадании в центр учета (Ц.У.) приводят к строго определенным изменениям в бухгалтерских отчетностях.

Пока я говорю о бумажных документах. В наш просвященный век, когда везде стоят компьютеры.... И нужна компьютерная система... может аналоги бумажек заведем и в компе? :-) правда, тогда единое понятие документ, во всяком случае в этой системе, делится на два - некий екзешник, для редактирования данных, составляющих информационную часть документа. В дельнейшем я не буду разделять понятия - екзешник и данные, а использую только одно понятие документ...

Еще один важный аспект: в принципе, любая компьютерная и бухгалтерская система имеет 2 уровня работы - "информационный" - показывает когда, для какого клиента и по какому поводу были произведены те или иные хозяйственные действия (то, что вылилось в создании, редактировании и сохранении (проводке) того или иного документа), и "чисто бухгалтерский" - на какие счета пошли те суммы, о которых говорится...

И так, документы. Документы "возникают" в процессе жизнидеятельности предприятия, "бумажные" копии их "разлетаются" в разные стороны, а сами они "оседают" в БАЗЕ первичных документов ("информационная" часть). Между документами и записями в Бухгалтерских книгах есть некая операция, которая называется "разноска" (а может так ее назвали мы (я не знаю)). Важно, что документу в целом, или каждой строке документа соответствует некоторое количество строчек в книге бухгалтерских операций, причем, естественно, разные по типу документы порождают разные "наборы" строк. Когда происходит разноска? да, по-большому счету, когда угодно, можно, наверное, и в конце месяца разнести все документы, которые были созданы на предприятии, а можно это делать автоматически, в момент сохранения документа в базе.

Что еще? Что делать, если организация заказчика распределенная, т.е. работает несколько центров учета(Ц.У.), и данные, несколько раз в день должны передаваться в центр управления (а может и обратно....). Представим себе структуру состоящую из "конторы", которая получает заказы, и нескольких цехов, разбросанных... ну, допустим, по региону, которые эти заказы выполняет... документопоток из заявок (нарядов) и "актов выполненных работ" будет встречным.... Мы услышали замечательный термин - "репликация". Очень понравилась идея - возможность работать, изредка обмениваясь данными. Как раз то, что нужно было нам.

Как организовать систему? Решили, что приятнее всего для хранения данных использовать SQL сервер, который быстро обрабатывает данные, имеет встроенную систему распределения прав и много чего другого... Что же делать с клиентами? - тут есть несколько подходов: можно сделать нечто "глобальное", с встроенным языком, и потом на этом языке уже описывать систему (в неких "внутренних" скриптах). Но, разработка языка и "виртуальной машины" для исполнения собственно скриптов, путь, конечно, не плохой, но очень трудоемкий - разработать нормальный язык описания задачи, придумать к нему "виртуальную машину"... У нас для этого просто не было времени.

Мы пошли другим путем. Взяли некий инструмент, на котором начали "ваять" "екзешники", каждый из которых в момент работы обменивается данными с сервером... Естественное, система учета это не один документ, и не одно клиентское рабочее место, даже если мы говорим об одном "Ц.У.". Нам никто не мешает поставить на клиентский компьютер несколько "екзешников", для редактирования тех документов, доступ к которым разрешен пользователю.

Но, если уж зашел разговор о "екзешниках", то какая разница, в какой системе их делать, т.е. какими языками пользоваться, главное, чтобы данные, для которых и затевается эта каша нормально представлялись и редактировались. Главным достоинством любой системы проектирования "екзешников" является скорость, удобство разработки и эргономичность полученного "екзешника".

И, если уж мы заговорили о большой системе, так надо говорить и об администрировании Прав Пользователей... да и администрировать "Ц.У." тоже как - то надо...

Вот, вроде с "предварительными замечаниями" я закончил...


Предыдущий Шаг | Следующий Шаг | Оглавление
Автор Голиброда Александр.