17.04.2006, 18:04 | #1 |
Участник
|
Господа, подскажите, пожалуйста, кто как реализует в Навижине "межфирменный учет" по-российски?
Ситуация следующая: есть торговая компания, представленная несколькими ИП, юр. лицами и т.д. Кто-то из них работает с НДС, кто-то без. Все они используют общий склад. Товары на склад закупают все юр.лица, продают так же все. Естественно, при этом возникает перекос, когда одно юр.лицо продает товар, реально закупленный другим юр. лицом. В итоге фактические остатки не соответствуют документальным: у одного юр.лица числится товар, которого нет, а другое юр.лицо продало товар, которого у него никогда и не было. Чтобы ликвидировать этот перекос, они задним числом оформляют липовые документы на закупку недостающего товара, но не у другого своего юр. лица, а у левого поставщика. Хотелось бы в Навижн видеть как общую информацию по компании в целом, так и по каждому юр. лицу в отдельности. При этом хотелось бы, чтобы Навижн сам генерировал эти "липовые" документы. Интересно узнать, как поступают грамотные внедренцы, когда сталкиваются с такими организациями? |
|
17.04.2006, 18:13 | #2 |
Navision
|
Юрлица ввести как измерения
|
|
17.04.2006, 19:31 | #3 |
Участник
|
Цитата:
На мой взгляд в автоматизации бизнеса "по русски" есть одно слабое место - это его постоянная изменчивость. Меняются схемы движения денег, товара. Сегодня у вас в цепочке две компании, завтра - три и т.д. А если практически, то мне известны две схемы, которые позволит автоматизировать Навижн: 1) разные юр. и физ лица вести в разных фирмах Навижн и затем консолидировать балланс; 2) вести все в одной фирме и делить данные, принадлежащие разним юр. и физ лицам с помощью какой-либо аналитики. Это если вы хотите все вести в одной системе. Можно вести все в Навижн и по каким-либо хитрым алгоритмам передавать данные в несколько других баз, например 1С. |
|
18.04.2006, 11:28 | #4 |
Moderator
|
Мда, действительно, обычно делают некий функционал по Юр.лицам. Мы сделали такой с весьма богатым наполнением ;-) Правда в любом случае, это сильно портит базу, функционал и пользователей. И я на 100% согласен с Sitizen, что это все очень изменчиво, особо в свете последнгих событий. И уже многие компании отказываются от такой практики, а это ох как сложно. К сожалению, невозможно убедить коммерсанта отказаться от такой схемы ради Навижина, поэтому дерзайте: программируйте или покупайте ;-)
|
|
19.04.2006, 12:35 | #5 |
Участник
|
|
|
24.04.2006, 16:56 | #6 |
Участник
|
соглашаясь по сути с Sitizen и остальными просто немного поподробней опишу вариант Ирули (и п.2 Sitizen)в том виде, как приходилось встречться (правда использовалась немного в других целях ):
ЮЛ - в глобальное измерение. Товарный запас жестко разбить по этому измерению (минус-контроль в его разрезе) При резервировании товара на уровне одного ЮЛ - в случае нехватки товара автоматическое создание внутреннего перемещения с другого ЮЛ (подразумевается создание системы приоритетов - откуда в каком случае брать товарный запас и в какой последовательности), его учет и продолжение резервирования товара. В итоге: имеем общий товарный запас, он же сразу побит по ЮЛ, на основании этих перемещений можно создать "липовые" документы и ... достаточно серьёзные (но выполнимые) доработки системы. Можно конечно половину работы на юзеров повесить и сделать только минус-контроль в разрезе измерения и при нехватке товара в текущем ЮЛ - пусть сами перемещают из других. |
|
24.04.2006, 17:33 | #7 |
Участник
|
А какая версия Навижна????
В 4-ке я видел какой-то функционал по интеркомпанейскому учету |
|
24.04.2006, 17:35 | #8 |
Участник
|
|
|
24.04.2006, 17:52 | #9 |
Участник
|
А, я только хочу приступить...
Хотя все зависит от того какие интеркомпанейские записи надо генерить - счета, записи по товарным движениям.... Проблема в каждоом случае нетривиальна. Например взять хотя бы доступы - бухгалтер одной фирмы не должен видеть другой а тогда интеркомпанейскую запись не создать... Геморрой это по моему и эти вещи надо писать уже после окончанию внедрения основного как добавку. Я жду 5-й Навижн - может там лучше. |
|
24.04.2006, 18:10 | #10 |
Участник
|
Абсолютно согласен... Поэтому я и уточнил, что "немного в других целях используется" ЮЛ всё же в одной базе одно
|
|
24.04.2006, 18:12 | #11 |
Участник
|
Цитата:
У нас работает проект с юр лицо глобальное измерение, доработки есть но выполнимые, мы еще СКЮ используем, это позволяет и себестоимость более корректно считать, плюс у нас разные юрлица с разным НДС тогргуют, это то же на СКЮ повесили, межфирменные продажи делаем через журнал заявок, весело довольно получается |
|
26.04.2006, 11:52 | #12 |
Участник
|
Добавлю к Ируле и a_mitin.
Используем юрлица в качестве глобального измерения. Для перемещения из одного ЮЛ на другое используем внутренние перемещения. Продажи в минус запретили. Вобщем-то получилось довольно не плохо, с минимальными доработками в функционале (не трогая отчетов, там полный пипец...) |
|
26.04.2006, 17:42 | #13 |
Участник
|
Цитата:
Сообщение от RobiBaggio
Добавлю к Ируле и a_mitin.
Используем юрлица в качестве глобального измерения. Для перемещения из одного ЮЛ на другое используем внутренние перемещения. Продажи в минус запретили. Вобщем-то получилось довольно не плохо, с минимальными доработками в функционале (не трогая отчетов, там полный пипец...) на нашем проектеи отчеты и печатные формы первичных документов работают нормально. |
|
26.04.2006, 18:01 | #14 |
Участник
|
Да у нас там специфическая отчетность...
|
|