В общем-то ничего очень уж смешного в стремлении к универсальности нет. Я когда-то, лет десять назад, написал подобную систему для учета операций торгового предприятия. Тогда еще на FPD 2.6, теперь она работает на MSSQL+VFP. В основе идеологии программы - документ. У бухгалтерских документов (счета, платежки, накладные и т.п.) есть ряд общих свойств, отличия описываются в справочнике видов документов, документы связываются между собой, к документам генерируются бухгалтерские проводки. У документов есть строки (товарные спецификации), которые также могут связываться друг с другом. В этом проекте сейчас порядка 50 таблиц, если бы этот же функционал делать традиционными методами (вид документа - таблица, а то и несколько), количество таблиц было бы на порядок-два больше и малейший "шаг в сторону" приводил бы к перепроектированию системы.

Называть это "документооборотом" не совсем корректно, это скорее документо-ориентированная система учета.

Цитата:

У бухгалтерских документов (счета, платежки, накладные и т.п.) есть ряд общих свойств

Но их очень мало: тип документа, контрагент, дата и номер документа, - далее начинаются различия.
Можно конечно наращивать справочник терминов документов и далее описывать документы в рамках этих терминов.

Prudivus, все это понятно и не вызывает возражений. Правда при наличии ключевого слова "бухгалтерских". И то, как отметил AleksM, с большой натяжкой. Если брать "не бухгалтерские" документы, то общих атрибутов становиться еще меньше: контрагента может и не быть.

Цитата:

Глубина знаний в области документооборота определяется конкретной задачей которую вы соизволите написать при помощи базовых диблиотек документооборота.

Я говорю не о пользовательской глубине знаний, а о знаниях программиста, который должен предусмотреть все возможные пользовательские потребности. Т.е. программист должен занть всё о документообороте
Ну или постановщик задачи.
Что такое "объект типа документ"?

RIVC
речь идет о универсальных библиотеках позволяющих сторить любой обьект типа документ, справочник, список и т.д. Берем такие библиотеки и на их базе создаем сдою описывающую конкрктные документы необходимые для твоего проекта и на выходе с минимальными усилиями получаем проект любой сложности приноящий прибыль.

Именно под такими же лозунгами уже участвовал в одном проекте. Могу рассказать, что из этого получилось.

RIVC
Ваша позиция предельно понятна и ясна.

Откуда такая уверенность? От обиды на непризнанность правильное понятие обычно не возникает.

Я всего лишь задал некоторые вопросы, которые должны быть предельно выяснены ДО проектирования. Кстати, на основании имеющегося практического опыта именно в этой области. Вам такой опыт не интересен?

Ответа пока нет.

ИМХО Контрагент будет всегда. Документ д.б. "от кого то" и "кому то"

Даже у внутренних документов (приказы)?

Да. Тот кто родил документ, тот и контагент.

Для начала надо определить сам термин "документ", создать формальное описание. Полагаю, что существует соответствующая теория.
Если автор выполнил работу, как он пишет, на 90%, то во-первых зачем обращаться за помощью, а во-вторых ему надо выдать нобелевскую премию Но по математике их не выдают.
К тому же математически описать документ вовсе не означает организовать документооборот





Исправлено 1 раз(а). Последнее : Влад Колосов, 20.03.07 16:39

Я сейчас как раз перепроектирую структуру документа, заодно с переходом на другую платформу (PostgreSQL). В нынешней (старой) версии у документа есть всего два поля для определения задействованных объектов учета: получатель и отправитель (yе считая даты, номера, валюты, суммы и т.п.). В новой версии я хочу выделить эти два поля в отдельную таблицу. чтобы у документа, в зависимости от типа, было N (0..N) именованных реквизитов типа "объект учета". Например, у документа может быть только один контрагент - получатель (платежка, счет). Или два: получатель-отправитель (накладная: отгрузка со склада, внутреннее перемещение). Три, четыре: получатель(склад)-отправитель(поставщик)-перевозчик-таможня... В общем, сколько нужно, столько и делается, в рантайме, на этапе настройки и внедрения/сопровождения.

ЗЫ. В декабре я тут выкладывал "проект xFields", расширение реквизитов документов в подобной системе в XML-образной форме.



Исправлено 1 раз(а). Последнее : Prudivus, 20.03.07 16:54

Влад, от слова "документооборот" сам автор уже давно открестился. Давай говорить о "документо-ориентированной системе учета".

ИМХО Тут скорее всего нужно говорить о некоем DocumentFrameWork, т.е это средство для разработчика.
А документо-ориентированный учёт имеет наглядное воплощение в 1С, только хард-кодинга там немерянное количество.

Ребята, а как же насчет вот этого?

RIVC
речь идет о универсальных библиотеках позволяющих сторить любой обьект типа документ, справочник, список и т.д. Берем такие библиотеки и на их базе создаем сдою описывающую конкрктные документы необходимые для твоего проекта и на выходе с минимальными усилиями получаем проект любой сложности приноящий прибыль.

Тут же не только документы фигурируют. Тут о чем-то более глобальном. И более универсальном.

Короче, ребята захотели написать конкурента 1С. Точнее его конфигуратору.

2AleksM

А что тогда делать с атрибутом "создатель"?

Создатель = Контрагент.

Цитата:

2AleksM
А что тогда делать с атрибутом "создатель"?

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



Исправлено 1 раз(а). Последнее : Prudivus, 20.03.07 17:13

Тогда следущий вопрос: а как быть с дублированием, быстродействием, размером трафика, нагрузкой на сервер?

Как обычно начинают все с рассказов о том, что документов будет немного. Но рассказывают обычно по опыту ручного создания таких документов. А такой способ сам по себе накладывает ограничения на количество создаваемых документов. Но при автоматизированном создании такого ограничения нет и все обычно завершается лавинообразным ростом табличек, хранящих такие документы. Это даже если контора маленькая.

Цитата:

все обычно завершается лавинообразным ростом табличек, хранящих такие документы

Совершенно верно! А если еще нужно строить и связи между документами, то просто финиш. Вот поэтому единая таблица документов (их шапок) и спасает ситуацию.

Цитата:

Цитата:
все обычно завершается лавинообразным ростом табличек, хранящих такие документы
Совершенно верно! А если еще нужно строить и связи между документами, то просто финиш. Вот поэтому единая таблица документов (их шапок) и спасает ситуацию.

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

Prudivus

Цитата:

все обычно завершается лавинообразным ростом табличек, хранящих такие документы

Совершенно верно! А если еще нужно строить и связи между документами, то просто финиш. Вот поэтому единая таблица документов (их шапок) и спасает ситуацию.

Я бы сказал не спасает, а дает некоторую надежду. Ибо в таком случае во весь рост встает вопрос организации поиска и анализа по произвольному сочетанию атрибутов.

Цитата:

Ибо в таком случае во весь рост встает вопрос организации поиска и анализа по произвольному сочетанию атрибутов.

Этот же вопрос встаёт при формировании бух. проводок по документу.