|  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 | 
| Участник | 
			
			С одной стороны можно посоветовать пользоваться средствами навика, т.к. с помощью его проще "оставить след" о проводке, которую Вы делаете в базе "б" на основании операции, проведенной в базе "а".  Логика может быть приблизительно такой: при проведении операции в базе "а" ложить в какую-то буфферную таблицу (журнал) операции, которые подлежат консолидации в другую базу "б" с уже измененными значениями. Периодически (или сразу при проведении операции) строки из этой таблички (журнала) базы "а" переносить в нужную базу "б". При этом можно создавать записи в какой-то другой табличке на подобии учтенных строк журнала в базе "а". Таким образом Вы на основании таблички учтенных строк вы получите историю проведения операций. Средства реализации Вам уже известны.  С другой стороны можно посоветовать реализовать это средствами ЕсКьюЕл. Главным преимуществом тут будет скорость выполнения таких операций. И если намечается большое кол-во операций, которые необходимо переносить и еще без всяких процедур одобрения, то средства сиквела могуть быть более приемлемыми. Из недостатков, то что я могу сейчас увидеть, - это сложность написания на языке запросов (громоздкость). | 
|  |