AXForum  
Вернуться   AXForum > Microsoft Dynamics NAV > NAV: Функционал
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 31.08.2005, 12:19   #1  
ShadowFromXZone is offline
ShadowFromXZone
Участник
Аватар для ShadowFromXZone
 
288 / 0 (1) +
Регистрация: 29.09.2003
Как учесть операции в разных БД SQL
Вот такой вопрос коллеги, ... посоветуйте как это лучше сделать
1. Одна и таже операция по разному разносится
а) в управленческий учет - 100 $
б) в РСБУ - 70$
2. Хочется чтобы БД а и б были физически разными SQL БД

Вопрос как это реализовать.. SQL процедурами или программированием в Navision?
Одим словом как заставить работать NAvision одновременно с двумя БД SQL
__________________
ERP - лохотрон для ТОП менеджмента :-) на большие бабки ;-)
Старый 31.08.2005, 12:31   #2  
DA_NEAL is offline
DA_NEAL
Участник
Аватар для DA_NEAL
Лучший по профессии 2017
Лучший по профессии 2009
 
787 / 54 (3) ++++
Регистрация: 05.08.2002
Адрес: Королев
Можно было бы еще добавить поля сумм для управленческого учета, типа Amount (For Managment) и .т.д. хотя до фига прикручивать придется....

А вам нужны полностью идентичные базы за исключением только сумм?


Вообще долго думаю мысль сделать Два плана счетов в Navision и сдублировать все настроечные таблицы для управленческого учета + дописать все учетные функции и привязать все управленческие привязки к объектам учета. При разноске операций обязать пользователя указывать не только стандартные учетные группы но и управленческие. В итоге в фин. книге операций заполнять поля Manage Account No., Manage Amount и т. д. Может делал кто уже?
Старый 31.08.2005, 16:25   #3  
Polar is offline
Polar
Участник
Аватар для Polar
 
281 / 74 (3) ++++
Регистрация: 28.07.2003
Адрес: Ростов-на-Дону
Странно, но обычно проблема управленческого учета состояла в объединении информации (например из нескольких фирм), получение разных закономерностей, построение прогнозов, выявление причин затрат и т.д.

А вы тут про черные флаги разговариваете, про двойную сами знаете что... ))
ну да ладно....

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

P.S. Ничем таким никогда не занимался и делать ничего не умею, поскольку противозаконно, это только лишь мои личные фантазии.
__________________
Удачи!
Старый 31.08.2005, 18:16   #4  
DA_NEAL is offline
DA_NEAL
Участник
Аватар для DA_NEAL
Лучший по профессии 2017
Лучший по профессии 2009
 
787 / 54 (3) ++++
Регистрация: 05.08.2002
Адрес: Королев
2 Polar
Примерно это я и имел ввиду
Старый 31.08.2005, 18:19   #5  
DA_NEAL is offline
DA_NEAL
Участник
Аватар для DA_NEAL
Лучший по профессии 2017
Лучший по профессии 2009
 
787 / 54 (3) ++++
Регистрация: 05.08.2002
Адрес: Королев
кроме того не всегда Управленческий учет можно сформировать на базе бухгалтерского. Очень часто сильно раходятя методики, так как под управленческим каждая компания подразумевает свое и затраты очень странно могут разносится... в основном касается рекламных расходов, подарков, спонсорской помощи, основных средств, определения управленческой себестоимости, прибыли и т.д. и. т.п. Прибавте сюда еще откаты и прочую лабуду.
Старый 01.09.2005, 17:55   #6  
TarasNBV is offline
TarasNBV
Участник
 
28 / 10 (1) +
Регистрация: 23.07.2005
Адрес: Ukraine
На сколько я понимаю , изюминка вопроса заключается в том, что необходимо консолидировать не просто данные нескольких фирм на одной базе данных - а есть несколько баз данных и данные необходимо переносить с одной компании одной базы в другую компанию другой базы.
Как вариант решения этой проблемы - предлагаю восспользоваться свойствами C\AL работать с OCX обьектами. Предварительно данный OCX (cfront.ocx) должен быть загружен в систему (regsvr32.exe [path to ocx file]).
Старый 01.09.2005, 18:09   #7  
DA_NEAL is offline
DA_NEAL
Участник
Аватар для DA_NEAL
Лучший по профессии 2017
Лучший по профессии 2009
 
787 / 54 (3) ++++
Регистрация: 05.08.2002
Адрес: Королев
Angry
2 TarasNBV

Не знаю как остальных... но меня вы несколько обидели... Так и хочется сказать что-нибудь обидное...
Старый 01.09.2005, 19:09   #8  
TarasNBV is offline
TarasNBV
Участник
 
28 / 10 (1) +
Регистрация: 23.07.2005
Адрес: Ukraine
Странно... Мне не понятно, как мой ответ мог кого-то обидеть, в частности Вас, многоуважаемый DA_NEAL!
Может Вы захотите обьяснить причину обиды?
Старый 02.09.2005, 09:06   #9  
DA_NEAL is offline
DA_NEAL
Участник
Аватар для DA_NEAL
Лучший по профессии 2017
Лучший по профессии 2009
 
787 / 54 (3) ++++
Регистрация: 05.08.2002
Адрес: Королев
просто судя по кол-ву постов ShadowFromXZone достаточно опытный специалист и явно рассматривал C/Front в качестве варианта решения задачи . И думаю участникам данного форума не нужно объяснять как зарегестрировать компонент.. Вопрос был что из C\AL или SQL лучше использовать. То, Что можно использовать и так понятно.


ЗЫ
А мой предыдущий пост это просто шутка... не воспринимайте серьезно .
Старый 02.09.2005, 11:03   #10  
TarasNBV is offline
TarasNBV
Участник
 
28 / 10 (1) +
Регистрация: 23.07.2005
Адрес: Ukraine
Что ж, приятно было узнать, что у некоторых участноков форума еще не потеряно чувство юмора.
Что же касается сути вопроса - то просил бы Вас посмотреть на итоговую строку вопроса:

Одим словом как заставить работать NAvision одновременно с двумя БД SQL
Старый 08.09.2005, 19:48   #11  
ShadowFromXZone is offline
ShadowFromXZone
Участник
Аватар для ShadowFromXZone
 
288 / 0 (1) +
Регистрация: 29.09.2003
Цитата:
просто судя по кол-ву постов ShadowFromXZone достаточно опытный специалист и явно рассматривал C/Front в качестве варианта решения задачи . И думаю участникам данного форума не нужно объяснять как зарегестрировать компонент.. Вопрос был что из C\AL или SQL лучше использовать. То, Что можно использовать и так понятно.


ЗЫ
А мой предыдущий пост это просто шутка... не воспринимайте серьезно .

Последний раз исправлено DA_NEAL 02-09-2005 в 09:09 [/B]
Совершенно правильное понимание вопроса - 5+


т.е. вопрос как это разрулить языком навижина
либо средствами MS SQL
__________________
ERP - лохотрон для ТОП менеджмента :-) на большие бабки ;-)
Старый 30.09.2005, 16:20   #12  
ShadowFromXZone is offline
ShadowFromXZone
Участник
Аватар для ShadowFromXZone
 
288 / 0 (1) +
Регистрация: 29.09.2003
есть у кого ни то каки е то соображения на этот счет
__________________
ERP - лохотрон для ТОП менеджмента :-) на большие бабки ;-)
Старый 30.09.2005, 18:38   #13  
Галина is offline
Галина
Участник
 
1,132 / 28 (3) +++
Регистрация: 01.07.2003
Боишься вам прямо и отвечать Предложишь совет-окажется-что сильно мелкий
Насколько я знаю-стандартных команд-которые обращались бы из одной Базы Навижина в другую Базу нет.
Межфирменной учет-построен-на выгрузке инф. в xml файл и загрузки в др.базу или фирму.
И из опыта знакомые сделали через c/front обращение к другой базе и подтягивают нужную информацию в свою базу.
Старый 30.09.2005, 18:57   #14  
TarasNBV is offline
TarasNBV
Участник
 
28 / 10 (1) +
Регистрация: 23.07.2005
Адрес: Ukraine
С одной стороны можно посоветовать пользоваться средствами навика, т.к. с помощью его проще "оставить след" о проводке, которую Вы делаете в базе "б" на основании операции, проведенной в базе "а".
Логика может быть приблизительно такой: при проведении операции в базе "а" ложить в какую-то буфферную таблицу (журнал) операции, которые подлежат консолидации в другую базу "б" с уже измененными значениями. Периодически (или сразу при проведении операции) строки из этой таблички (журнала) базы "а" переносить в нужную базу "б". При этом можно создавать записи в какой-то другой табличке на подобии учтенных строк журнала в базе "а". Таким образом Вы на основании таблички учтенных строк вы получите историю проведения операций. Средства реализации Вам уже известны.

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

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Ошибки задания Корр.Себестоимости - Товар операции. DeSp NAV: Функционал 6 05.04.2006 16:49
__Переход с БД Navision на MS SQL__ kgenius NAV: Администрирование 1 08.02.2006 11:46
Создание связи 2-х баз Nav, расположенных на разных SQL серверах Greek NAV: Программирование 1 20.09.2005 16:55
Navision - SQL Server. Открытие БД. Mary NAV: Администрирование 0 30.03.2005 19:03
По-разному работает группировка в фин. отчетах под Native и SQL Adios NAV: Администрирование 2 20.07.2004 18:15
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 13:26.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.