Общий план счетов для нескольких фирм

[UGT]

Здравствуйте,
хотелось бы получить совет опытных внедренцев

Существует компания, имеющая 2 юридических лица. Я хочу сделать для обоих юрлиц единый план счетов (и соответственно книгу финансовых операций), т.е. ф любой фирме в навижн будут видны операции, созданные из другой фирмы. Разделять эти операции я хочу с помощью глобального измерения - все операции будут помечены измерением Фирма.
С одной стороны, мы получаем удобство финансового анализа - можем легко посмотреть обороты как по любой из фирм, так и по всем вместе. С другой стороны, я не знаю, как такая настройка скажется на ведении бухгалтерского учета (пока он в Navision вестись не будет, но кто знает, как там в будущем...)

В общем, хотелось бы услышать мнения по этому поводу опытных специалистов, может какие подводные камни тут есть...

[rmv]

Возможно проще учет вести в отдельных фирмах, а учтенные операции из обеих сводить в третью фирму (консолидатор).
Касаемо реализации:
Вариант 1. Сделать книги операций общими для всех фирм.
Вариант 2. При учете в одной фирме перегонять записи в книгах в соседнюю фирму.
Вариант 3 (консолидация). Разделить операции по диапазонам. Ввести диапазон операций для фирмы (0..20 000 000, 20 000 2001.. 40 000 000). И при учете присваивать очередной номер из диапазона. Далее периодическим заданием переносить учтенные операции в фирму-консолидатор.
Вариант 4 (пойти другим путем). Организовать учет 2 юр. лиц в одной фирме, разделив по измерениям. .

Последствия:
Вариант 1. Непредсказуемо. Зависит от того будут ли дублироваться клиенты, поставщики, товары ... etc. Возможно слетят применения товарных операций, бухи будут применять платежи одного юр. лица к счетам другого. Могут возникнут проблемы вроде Клиент Бла-Бла не существует (книга операций общая, справочники разделены по фирмам)
Вариант 2. Аналогично варианту 1.
Вариант 3. Жду критики .

[Галина]

Цитата:

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

Возможно проще учет вести в отдельных фирмах, а учтенные операции из обеих сводить в третью фирму (консолидатор).
Касаемо реализации:
Вариант 1. Сделать книги операций общими для всех фирм.
Вариант 2. При учете в одной фирме перегонять записи в книгах в соседнюю фирму.
Вариант 3 (консолидация). Разделить операции по диапазонам. Ввести диапазон операций для фирмы (0..20 000 000, 20 000 2001.. 40 000 000). И при учете присваивать очередной номер из диапазона. Далее периодическим заданием переносить учтенные операции в фирму-консолидатор.

Сорри-но более бредового я еще не видела и не слышала.
Зачем предлагать-то что сразу не реально?
Открыть книги операций по фирмам????

[rmv]

Цитата:

Сообщение от Галина

Цитата:

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

Возможно проще учет вести в отдельных фирмах, а учтенные операции из обеих сводить в третью фирму (консолидатор).
Касаемо реализации:
Вариант 1. Сделать книги операций общими для всех фирм.
Вариант 2. При учете в одной фирме перегонять записи в книгах в соседнюю фирму.
Вариант 3 (консолидация). Разделить операции по диапазонам. Ввести диапазон операций для фирмы (0..20 000 000, 20 000 2001.. 40 000 000). И при учете присваивать очередной номер из диапазона. Далее периодическим заданием переносить учтенные операции в фирму-консолидатор.

Сорри-но более бредового я еще не видела и не слышала.
Зачем предлагать-то что сразу не реально?
Открыть книги операций по фирмам????

Извиняю .
Бредовая как Вы выразились идея разделить номера операций по диапазонам гарантирует уникальность первичного ключа (номера операции) на всех рабочих фирмах (всех базах если угодно). Справочники и документы разделяются по сериям номеров, что опять таки гарантирует уникальность первичного ключа на всех фирмах . Далее у нас все сводится в консолидатор сиквельной репликацией (есть и другие механизмы). Вот такая бредятина-с.. . Что же здесь нереального?

[Галина]

Цитата:

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

Извиняю .
Бредовая как Вы выразились идея разделить номера операций по диапазонам гарантирует уникальность первичного ключа (номера операции) на всех рабочих фирмах (всех базах если угодно). Справочники и документы разделяются по сериям номеров, что опять таки гарантирует уникальность первичного ключа на всех фирмах . Далее у нас все сводится в консолидатор сиквельной репликацией (есть и другие механизмы). Вот такая бредятина-с.. . Что же здесь нереального?

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

[rmv]

Цитата:

Сообщение от Галина

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

Ух, сколько эмоций. Вас наверно шокирует, но совсем немного, только присвоение NextEntryNo .
У меня это заняло около дня, с тестированием два дня .
12, 22, кодеюнит, коррекцию курсовых разниц.
Больше для данного проекта не потребовалось.

[GalaM]

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

Придется думать про непересекающую нумерацию справочников поставщиков, клиентов, ОС (они используются в поле Источник Но.), взаимосвязь аналитических измерений и пр.

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

С другой стороны, если у Вас только упр. учет - не бухгалтерский, такое возможно, но зачем вообще тогда вести 2 фирмы? Работайте в одной и допишите возможность формирования документов продажи (и др. внешних документов) от лица одной или другой компании, например, ориентируясь на измерение. При такой организации вы потом, если надо, разделить одну компанию на 2

[IGG]

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

[UGT]

Цитата:

Последствия:
Вариант 1. Непредсказуемо. Зависит от того будут ли дублироваться клиенты, поставщики, товары ... etc. Возможно слетят применения товарных операций, бухи будут применять платежи одного юр. лица к счетам другого. Могут возникнут проблемы вроде Клиент Бла-Бла не существует (книга операций общая, справочники разделены по фирмам)

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

А возможно ли в стандартном функционале реализовать консолидацию товарных операций?

[rmv]

Цитата:

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

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

А возможно ли в стандартном функционале реализовать консолидацию товарных операций?

Ситуацию с применениями в принципе можно разрулить используя разные склады для разных фирм.. Только оно Вам надо? Проблемы (фильтрация по измерениям) будет те же что если вести учет для разных юр. лиц в одной фирме.

Мы решали задачу консолидации разделив номера операций по диапазонам с последующим сведением в консолидированную базу.

[Sitizen]

Хотелось бы сказать, что "видеть общие обороты" и "получать консолидированную отчетность" - это немного разные вещи.
В консолидированной отчетности отсутствуют внутрифирменные операции. Прибыль, соответсвенно, считается с учетом этого.
Т.е.если есть цель в итоге получать именно КОНСОЛИДИРОВАННУЮ отчетность, то первый вариант не покрывает ваших потребностей - придется еще и дорабатывать отчетность.
Кстати вопрос возник - а как вы будете закрывать периоды при такой схеме? Ведь необходимо видеть балланс для каждого юр лица и для компании в целом, а это, повторюсь, разные вещи.
Это что касается методологии учета.
Что касается технологии, то наверняка будет еще куча подводных камней, каких не знаю.

Мой совет - делать две фирмы и третью консолидирующую.
Это отвечает идеологии Navision, а мой опыт подсказывает, что пути, не отвечающие ей, тернисты.

[UGT]

Цитата:

И главное, а чем все таки не устраивает вариант с консолидацием?

Такой вариант устраивает, просто казалось я нашел элегантное решение с минимальными трудозатратами

Что касается тернистости нестандартного пути - согласен на все 100!

[GalaM]

Цитата:

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

Цитата:

И главное, а чем все таки не устраивает вариант с консолидацием?

Такой вариант устраивает, просто казалось я нашел элегантное решение с минимальными трудозатратами

Что касается тернистости нестандартного пути - согласен на все 100!

Да, действительно, казалось.
Трудно сказать, к чему может привести такая экономия.

[RobiBaggio]

2UGT
Я делал такую вещь, холдинг, 8 юр лиц. Все в одной базе. Учет разделяли измерениеми.
НО! Не делали бухгалтерию. Хотя, я особых проблем не вижу. Так как все операции разделены измерением, построить бух учет можно.

[GalaM]

Цитата:

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

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

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

Если у Вас гл. книга общая. Вы все-равно видите все операции, пока фильтр не поставите
Я и подумала, что проблемы с организацией доступа нет.

[Borr]

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

[rov_imported]

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

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

Вариант с 2-мя фирмами и третьей консолидирующей неплох - но только в теории В реальности
будет куча гемороя по переносу информации - если конечно не только фин. книга будет перетягиваться. Это будет сложно.

А про вариант с диапазонами номеров в фин. книге - вообще не понял. 2 фирмы - и у каждой свой диапазон номеров в фин. книге? А зачем? Кто мешает обе фин. книги потом переписать в третью фирму?
Номер в этой третьей фирме будет генерироваться по порядку - только и всего. Или я не так понял?

[UGT]

Цитата:

Как опытный внедренец могу посоветовать использовать все-таки одну фирму и глобальное измерение.

Т.е. в одной фирме, а не в нескольких фирмах с общими таблицами?
Одно юрлицо работает с НДС, а другое - без. Пока я смутно могу представить, как это вести в одной фирме... Проставлять в каждый конкретный заказ продажи НДС Бизнес Группу?
Опять же проблема печатать документы с разными реквизитами. Насколько трудоемки такие изменения?
И как быть с расчетом себестоимости? У нас одно юрлицо продает товар как сторонним клиентам, так и второму юрлицу, а оно, в свою очередь, тоже продает товар (уже в розницу) по другим ценам.
Проблема разделения проав доступа на уровне фирм для нас не актуальна.

Боюсь, с такими изменениями первое же обновление превратится в стихийное бедствие...

[RobiBaggio]

Цитата:

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

Цитата:

Как опытный внедренец могу посоветовать использовать все-таки одну фирму и глобальное измерение.

Т.е. в одной фирме, а не в нескольких фирмах с общими таблицами?
Одно юрлицо работает с НДС, а другое - без. Пока я смутно могу представить, как это вести в одной фирме... Проставлять в каждый конкретный заказ продажи НДС Бизнес Группу?
Опять же проблема печатать документы с разными реквизитами. Насколько трудоемки такие изменения?
И как быть с расчетом себестоимости? У нас одно юрлицо продает товар как сторонним клиентам, так и второму юрлицу, а оно, в свою очередь, тоже продает товар (уже в розницу) по другим ценам.
Проблема разделения проав доступа на уровне фирм для нас не актуальна.

Боюсь, с такими изменениями первое же обновление превратится в стихийное бедствие...

2UGT
Все что Вы перечислили реализовали. Правда пришлось переписывать очень много.
В настоящее время.
Компании между собой двигают товар на комиссию, ответ. хранение. Дальше идет реализация со склад ответ хранения.
Документы печатаются.
Себестоимость расчитывается как общая для всего холдинга.
Отмечу, что бухгалтерия ведется в 1С.

[rov_imported]

Цитата:

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

Т.е. в одной фирме, а не в нескольких фирмах с общими таблицами?

Да.

Цитата:

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

Одно юрлицо работает с НДС, а другое - без. Пока я смутно могу представить, как это вести в одной фирме... Проставлять в каждый конкретный заказ продажи НДС Бизнес Группу?

А для чего вообще существуют настройки НДС?! Заведите разные НДС бизнес и НДС Товарные группы -и настройте как вам надо: где надо - с НДС, где не надо - без НДС.

Цитата:

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

Опять же проблема печатать документы с разными реквизитами. Насколько трудоемки такие изменения?

Да, по умолчанию настройки самой фирмы берутся из таблички "Фирма Информация". Тут придется переделать. Либо добавить поля в эту табличку и обращаться к ним в отчетах. Либо эти поля
добавить в табличку измерения(или вообще сделать новую) - если возможен случай, когда число фирм будет расти. Сложного в этом вообще ничего нет.

Цитата:

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

И как быть с расчетом себестоимости? У нас одно юрлицо продает товар как сторонним клиентам, так и второму юрлицу, а оно, в свою очередь, тоже продает товар (уже в розницу) по другим ценам.

А при чем здесь себестоимость?? Вы не путаете цены, по которым вторая фирма продает и себестоимость?

Цитата:

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

Боюсь, с такими изменениями первое же обновление превратится в стихийное бедствие...

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