Планировать легче когда план один


[ Пpишедшие ответы ] [ Отпpавьте свой ответ ] [ Пеpеговоpный пункт ] [ FAQ ]

Posted by Владимир Секретёв (65.48.81.63) on December 23, 2002 at 18:09:30:

In Reply to: О нескольких планах счетов и не только... posted by Юрий Шкурат, г. Севастополь on December 23, 2002 at 03:21:04:

А почему вопрос о двух деревьях/планах счетов возник только сейчас?

Действительно, почему? Предпримим попытку анализа.

Первый вопрос, который мы должны решить, заключается, как ни старнно, в том, а что понимать под "вторыми" деревом и планом счетов?

Вероятно имеется ввиду второй физический файл, полностью, при этом, идентичный по структуре и способу хранения информации. Примем это за основу.

Программа существует более 10 лет, и до этого момента не возникал вопрос о мультипликации фалов данных. Нет, простите, возникал. После появления extrd.dat дискуссировалась возможность иметь несколько дисковых баз, одну для более перманентных данных, другую как хранилище временной информации, буфер и т.д. Но как инструмент ведения объединенно-дифференцированного учета - нет, такого не было (я не слышал).

Опыт эксплуатации, вероятно, позволяет предположить, что это просто не нужно.

Попробую пояснить. План счетов не является фиксированной структурой. Ничего не мешает в ФИЗИЧЕСКИ одном плане счетов создать ФАКТИЧЕСКИ два или более. Многие этим широко пользуются, причем естественным образом, и нужды разрезать план на два файла не возникает.

Приведу пример, в котором многие, вероятно, увидят знакомый подход.

Часть плана счетов представляет собой тот план, который утверждается Мин.Фин.

01-Основные ср-ва
02-Износ осн. ср-в.
....
51-Расчетный счет
76-Разные дебиторы-кредиторы
...
BANK - Банки
ORG - Организации
...

Что это за BANK и ORG? А это как раз и есть тот самый "второй" план счетов. Ведутся эти счета в разрезе предприятий, на них запоминается кто сколько и кому должен - вот он, управленческий учет!

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

С моей точки зрения, выделение части плана счетов в отдельный файл только усложнит жизнь разработчику приложений. Надо будет помнить в каком файле тот или иной счет, указывать его, следить, чтобы одинаковых счетов не завелось ...

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

Предположим, физическое лицо зарегистрировалось как предприниматель БОЮЛ и открыло ОДИН расчетный счет в банке. Через некоторое время оно, это лицо, зарегистрировало иной вид деятельности, но продолжат пользоваться тем же счетом в банке для расчетов по ОБОИМ видам деятельности. В этом случае это лицо вынуждено вести ОДНУ банковскую книгу, но сдавать ДВА РАЗНЫХ отчета.

И опять ни 2 плана счетов ни 2 дерева не дают никакого преимущества перед имеющейся системой. Берем ОДНО дерево и в каждую ветвь добавляем уточнение, к какому виду предпринимательской деятельности относится данная транзакция. Задача решена.

Если уж совсем невмоготу, или встает задача разделения уровней доступа, то можно вырастить два дерева в одном файле cas.rul.


Так что, думаю, вопрос о двух планах счетов возник сечас именно и только благодаря появлению Адаптера и лишь потому, что этот Адаптер обслуживает ... ДВЕ директории обмена. Это раздвоение, мне кажется, слегка смутило уважаемых разработчиков, особенно ввиду конца отчетного года.

Если бы Адаптер, или просто Сервер ФБП получил возможность обслуживать ОДНУ базу, в которой накоплены данные за НЕСКОЛЬКО лет, и через ОДИН каталог обмена, то смуты бы не возникло.




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



Отпpавьте свой ответ

Name:
E-Mail:

Subject:

Comments:
Link URL:
(можно не вводить)
Link Title:
(можно не вводить)
Image URL:
(можно не вводить)
ВАЖНО: Если отпpавленное сообщение не будет видно сpазу в
списке сообщений, нажмите клавишу Reload в browser'e.


[ Пpишедшие ответы ] [ Отпpавьте свой ответ ] [ Пеpеговоpный пункт ] [ FAQ ]