Объединение учетов

[insoda]

Эта ветка дополняет ветку Разделение учетов

Какие преимущества ведения оперативного-управленческого и бухгалтерского/налогового учетов в единой базе данных? Буду рад если кто-нибудь подскажет ветки где это уже обсуждалось.

[Insane]

Ну как минимум такие, что инсталляция нескольких БД согласно лицензионного соглашения требует приобретения такого же количества серверных частей АХАРТы, в протвном случае является нарушением этого же самого лицензионного соглашения.

[insoda]

То есть дешевле с точким зрения лицензии. А есть ли какие-нибудь методологические/технические приемущества?

[glibs]

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

[insoda]

Да, это второе преимущество. Изначальное отсутствие двойного ввода, без необходимости организации обмена между базами данных.

[Insane]

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

[insoda]

Что Вы имеете ввиду?

[ALEG]

Ну наверное в идеале (когда учеты сопоставимые), то это (ведение одной системы учета) позволяет исключить двойной ввод и уменьшить кол-во ошибок. Например, резко уменьшается риск позднего отражения расходов по авансовому отчету в управленческом учете, так как бухгалтер шкуру снимет если в течении 3 дней не сдадут.
Или другими словами обеспечение качества данных будет контролироваться большим количеством пользователей.

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

Хочу обратить внимание на сознательную замену термина "в одной инф. базе" на "одну инф систему", так как в 1С например учет можно вести в физически одной базе, но это будут две абсолютно разные системы учета с несопоставимым набором данных.
В SAP некоторые модули подразумевают отдельные базы данных при том, что данные абсолютно сопоставимые (только затраты на поддержку сопоставимости могут быть выше).

[insoda]

Что такое сопоставимые данные? Это одни и теже аналитические разрезы?

[ALEG]

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

[Insane]

Ну давайте рассмотрим наиболее частые варианты различных учетов:
1. Просто различные планы счетов. Проблема решается либо выделением отдельной аналитики под управленческий счет либо банальной трансляцией данных. Возможны вариации с разными валютами учета в бухгалтерском и управленческом учете - решается либо модифицированной трансляцией либо стандартной вторичной валютой.
2. Варианты когда различие по учетам состоит в составе операций то есть в одном учете есть операции, отсутствующие в другом и наоброт - решается двойным вводом данных, либо доработкой системы если случаи отличий алгоритмизируемы
3. Случаи когда в управленческом учете операции проводятся совсем по другим принципам чем в бухгалтерском, например по ОС (решается стандартной функциональностью) или по складу (например в БУ - средняя, а в управленческом учете ФИФО).
4. Случай черно-белого учета, где в управленческом учете проводятся одни операции, а в бухгалтерском учете идут они же, но не в полном объеме, другими датами, с другими контрагентами и суммами.

[ALEG]

случаи 1 и 3 дадут сопоставимые данные. Т.е. их можно сопоставить по каким то правилам.
Случай 4 - сопоставить данные невозможно. Просто 2 набора данных.
Случай 2 тоже не сопоставимые.

Мой комментарий был по качеству данных. В идеальном случае (1 и 3) все нормально. Но в реальности что-то не внесли, что-то с ошибкой и при ведении в 2 разных базах получаем 2 набора ошибок. Чему верить - незнаю.

[Insane]

Цитата:

Сообщение от ALEG

случаи 1 и 3 дадут сопоставимые данные. Т.е. их можно сопоставить по каким то правилам.

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

[Insane]

А вообще мы отошли от исходного вопроса о необходимости единой или нескольких Бд для различных видов учета и как следствие минимизации двойного ввода.

[insoda]

Второе преимущество: изначальное отсутствие двойного ввода сопоставимых данных, без необходимости организации обмена между базами данных. Но двойной ввод сопоставимых данных позволят выявить ошибки ввода Сопоставимость - это возможность получить одни данные из других рассчетным путем. Зачем в УУ и БУ разные методы списания себестоимости?

[Insane]

Двойной ввод в 10% случаев выявляет ошибки ввода, а в 90% случаев их генерирует.
Насчет себестоимости УУ и БУ - всяко бывает зависит от существующей учетной политики и фантазии финансистов-управленцев. Я просто привел примеры ситуаций, с которыми сталкивался на проектах.

[Insane]

Кстати это одна из причин почему в большинстве случаев при двойном вводе в период тестовой эксплуатации в двух системах невозможно или очень трудно сверить результаты и разрести полученные различия в данных на:
1. ошибки ввода
2. различия в ПС
3. особенности функционирования систем
и т.д.

[insoda]

Понятно. Двойной ввод сопоставимых данных - однозначно плохо. Для несопоставимих данных двойного ввода не избежать. Но однокоратно вводить сопоставимые данные можно и ведя учет в нескольких БД организовавав обмен данными между БД.Но это сложно.
Зачем финансистам разная себестоимость по УУ и БУ?

[ALEG]

Цитата:

Сообщение от insoda

Зачем финансистам разная себестоимость по УУ и БУ?

Все просто,
В целях минимизирования налогооблагаемой базы по налогу на прибыль лучше списывать по методике FIFO (например, для того, чтобы более дорогие последние закупки списывались быстрее), а для управленческого учета лучше по LIFO ну например потому, что реально продается сначала наиболее поздняя партия пива (а то срок годности кончится)

[insoda]

Если идти до конца, то оптимизировать налоги лучше в разных БД?