31.08.2005, 12:19 | #1 |
Участник
|
Как учесть операции в разных БД SQL
Вот такой вопрос коллеги, ... посоветуйте как это лучше сделать
1. Одна и таже операция по разному разносится а) в управленческий учет - 100 $ б) в РСБУ - 70$ 2. Хочется чтобы БД а и б были физически разными SQL БД Вопрос как это реализовать.. SQL процедурами или программированием в Navision? Одим словом как заставить работать NAvision одновременно с двумя БД SQL
__________________
ERP - лохотрон для ТОП менеджмента :-) на большие бабки ;-) |
|
31.08.2005, 12:31 | #2 |
Участник
|
Можно было бы еще добавить поля сумм для управленческого учета, типа Amount (For Managment) и .т.д. хотя до фига прикручивать придется....
А вам нужны полностью идентичные базы за исключением только сумм? Вообще долго думаю мысль сделать Два плана счетов в Navision и сдублировать все настроечные таблицы для управленческого учета + дописать все учетные функции и привязать все управленческие привязки к объектам учета. При разноске операций обязать пользователя указывать не только стандартные учетные группы но и управленческие. В итоге в фин. книге операций заполнять поля Manage Account No., Manage Amount и т. д. Может делал кто уже? |
|
31.08.2005, 16:25 | #3 |
Участник
|
Странно, но обычно проблема управленческого учета состояла в объединении информации (например из нескольких фирм), получение разных закономерностей, построение прогнозов, выявление причин затрат и т.д.
А вы тут про черные флаги разговариваете, про двойную сами знаете что... )) ну да ладно.... В этом случае, дублировать план счетов не обязательно, можно его слегка расширить, добавить настройку для видимости только избранным. Таблицы настройки просто дополнить новыми полями, в результате чего на те же группы учета можно будет повесить дополнительные операции, ну и естесственно немного переделать учет. Но это уже от специфики предприятия. )) P.S. Ничем таким никогда не занимался и делать ничего не умею, поскольку противозаконно, это только лишь мои личные фантазии.
__________________
Удачи! |
|
31.08.2005, 18:16 | #4 |
Участник
|
2 Polar
Примерно это я и имел ввиду |
|
31.08.2005, 18:19 | #5 |
Участник
|
кроме того не всегда Управленческий учет можно сформировать на базе бухгалтерского. Очень часто сильно раходятя методики, так как под управленческим каждая компания подразумевает свое и затраты очень странно могут разносится... в основном касается рекламных расходов, подарков, спонсорской помощи, основных средств, определения управленческой себестоимости, прибыли и т.д. и. т.п. Прибавте сюда еще откаты и прочую лабуду.
|
|
01.09.2005, 17:55 | #6 |
Участник
|
На сколько я понимаю , изюминка вопроса заключается в том, что необходимо консолидировать не просто данные нескольких фирм на одной базе данных - а есть несколько баз данных и данные необходимо переносить с одной компании одной базы в другую компанию другой базы.
Как вариант решения этой проблемы - предлагаю восспользоваться свойствами C\AL работать с OCX обьектами. Предварительно данный OCX (cfront.ocx) должен быть загружен в систему (regsvr32.exe [path to ocx file]). |
|
01.09.2005, 18:09 | #7 |
Участник
|
2 TarasNBV
Не знаю как остальных... но меня вы несколько обидели... Так и хочется сказать что-нибудь обидное... |
|
01.09.2005, 19:09 | #8 |
Участник
|
Странно... Мне не понятно, как мой ответ мог кого-то обидеть, в частности Вас, многоуважаемый DA_NEAL!
Может Вы захотите обьяснить причину обиды? |
|
02.09.2005, 09:06 | #9 |
Участник
|
просто судя по кол-ву постов ShadowFromXZone достаточно опытный специалист и явно рассматривал C/Front в качестве варианта решения задачи . И думаю участникам данного форума не нужно объяснять как зарегестрировать компонент.. Вопрос был что из C\AL или SQL лучше использовать. То, Что можно использовать и так понятно.
ЗЫ А мой предыдущий пост это просто шутка... не воспринимайте серьезно . |
|
02.09.2005, 11:03 | #10 |
Участник
|
Что ж, приятно было узнать, что у некоторых участноков форума еще не потеряно чувство юмора.
Что же касается сути вопроса - то просил бы Вас посмотреть на итоговую строку вопроса: Одим словом как заставить работать NAvision одновременно с двумя БД SQL |
|
08.09.2005, 19:48 | #11 |
Участник
|
Цитата:
просто судя по кол-ву постов ShadowFromXZone достаточно опытный специалист и явно рассматривал C/Front в качестве варианта решения задачи . И думаю участникам данного форума не нужно объяснять как зарегестрировать компонент.. Вопрос был что из C\AL или SQL лучше использовать. То, Что можно использовать и так понятно.
ЗЫ А мой предыдущий пост это просто шутка... не воспринимайте серьезно . Последний раз исправлено DA_NEAL 02-09-2005 в 09:09 [/B] т.е. вопрос как это разрулить языком навижина либо средствами MS SQL
__________________
ERP - лохотрон для ТОП менеджмента :-) на большие бабки ;-) |
|
30.09.2005, 16:20 | #12 |
Участник
|
есть у кого ни то каки е то соображения на этот счет
__________________
ERP - лохотрон для ТОП менеджмента :-) на большие бабки ;-) |
|
30.09.2005, 18:38 | #13 |
Участник
|
Боишься вам прямо и отвечать Предложишь совет-окажется-что сильно мелкий
Насколько я знаю-стандартных команд-которые обращались бы из одной Базы Навижина в другую Базу нет. Межфирменной учет-построен-на выгрузке инф. в xml файл и загрузки в др.базу или фирму. И из опыта знакомые сделали через c/front обращение к другой базе и подтягивают нужную информацию в свою базу. |
|
30.09.2005, 18:57 | #14 |
Участник
|
С одной стороны можно посоветовать пользоваться средствами навика, т.к. с помощью его проще "оставить след" о проводке, которую Вы делаете в базе "б" на основании операции, проведенной в базе "а".
Логика может быть приблизительно такой: при проведении операции в базе "а" ложить в какую-то буфферную таблицу (журнал) операции, которые подлежат консолидации в другую базу "б" с уже измененными значениями. Периодически (или сразу при проведении операции) строки из этой таблички (журнала) базы "а" переносить в нужную базу "б". При этом можно создавать записи в какой-то другой табличке на подобии учтенных строк журнала в базе "а". Таким образом Вы на основании таблички учтенных строк вы получите историю проведения операций. Средства реализации Вам уже известны. С другой стороны можно посоветовать реализовать это средствами ЕсКьюЕл. Главным преимуществом тут будет скорость выполнения таких операций. И если намечается большое кол-во операций, которые необходимо переносить и еще без всяких процедур одобрения, то средства сиквела могуть быть более приемлемыми. Из недостатков, то что я могу сейчас увидеть, - это сложность написания на языке запросов (громоздкость). |
|
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|