Attain. Можно ли как-то вести несколько фирм в одной БД?

[Evgeniy]

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

[komar]

Смотря что надо с ними делать. Можно, например, вытянуть код фирмы на глобальные измерения.
В чем проблема, чем не устраивают "фирмы" Навижна?

[Evgeniy]

Проблема в том, что непонятно, как хранить взаиморасчеты между фирмами. Собственно, там понятия такого нет, ведь "фирма" в терминологии attain - это разделитель базы. А нужно хранить некий справочник фирм, их взаиморасчеты с клиентами и друг с другом. Вариант с измерениями понятен, я сам о нем думал. Я так понимаю, это единственный вариант?

[komar]

А почему нельзя вести расчеты? Можно.
Если весь вопрос в том, что нужно передавать электронные документы, то стандартным средством считается Commerce Gateway. Но не советую увлекаться - проблема неоднократно обсуждалась - дело в том, что отгрузка товара или оплата в одной компании вовсе не обязательно означает приемку товара или денег в другой.
Если необходимо видеть состояние взаиморасчетов - то разделение на фирмы этому не мешает. Если нужно консолидировать информацию - есть консолидация.
Или еще подробнее описание проблемы....

[Pavel Titov]

Тоже сейчас обеспокоен данной проблемой. Фирмы, действительно, понимаются в Навижне не так, как понимаем их мы. Если разделить данные по фирмам, не станет видно общих складов и клиентов.
Вижу наиболее простой путь решения проблемы - через аналитические измерения. Каждой транзакции (покупка-продажа) присваивать измерение СПД (субъект предпринимательской деятельности) со значением, равном СПД, осуществляющего расчет (СПД1, СПД2, ...). Все виды транзакций так же учитывать еще в одном разрезе - управленческом и бумажном. Бумажные - те, которые происходят только на бумаге, управленческие - по факту. Соответственно, периодически приходится генерировать такие "бумажные" транзакции для передачи товаров из одной фирмы в другую.
Вижу ряд проблем такого подхода, например то, что в большинстве своем придется переписывать Навижн, а такое вряд ли хочется.
Может, кто предложит более изящное решение...
PS: Глядел брошюрки по Аксапте, там оно уже реализовано стандартно. Почему в Аттейне не торопятся, не понимаю...

[Михаил Андреев]

Цитата:

Изначально опубликовано Pavel Titov
Тоже сейчас обеспокоен данной проблемой. Фирмы, действительно, понимаются в Навижне не так, как понимаем их мы. Если разделить данные по фирмам, не станет видно общих складов и клиентов.

На самом деле, никто не мешает часть данных сделать общими. Например, список клиентов, товары и т.д. Достаточно изменить один флажок у соответствующих таблиц. Правда, такой красоты с виртуальными компаниями и автоматическим созданием закупок/заказов, как в Аксапте, там нет.

[Khodakovska]

На сколько я правильно поняла у меня была аналогичная проблема
Т .е . в одной базе существуют различные фирмы с отдельными таблицами.

Существовало 2 варианта
1. Фирма A создает Sales order автоматически создается Purchase order в фирме B
Делаешь post invoice в фирме B для Purchase order автоматически создается posted Sales invoice в фирме A

2. Если клиент делает Sales order в фирме А то автоматически создается Purchase order в фирме А + Sales order в фирме B

Post все orders аналогично как и в первом случае только за один раз создаются
3 posted invoice ну и конечно же posted ships
Если кому-то интересно могу набросать схему решения

Делаю уже вторую такую работу Правда первая была полегче т. к .таблицы Item,Customer были общими .У нас это называется InterCompany

[Grizzly]

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

[komar]

Если это вопрос по программированию, то класс вроде бы назватся ChangeCompany

[Grizzly]

Век живи - век учись Спасибо, не знал.

Хорошо, доступ к данным получили. А как теперь вызвать учетную процедуру?

Например, нам нужно учесть финансовый журнал другой компании. Мы передаем в codeunit 231 переменную, которая ссылается на записи в нужной нам компании. Однако в учетной процедуре происходит обращение ко многим другим таблицам (измерения, клиенты, поставщики, счета, фин. книга операций и т.д.). Причем, если некоторые таблицы можно сделать общими, то делать общей фин. книга операций не имеет смысла (зачем тогда содавать фирмы). И так как эти записи не переназначаются, то, скорее всего, будут ссылаться на записи в текущей компании. Поэтому автоматически выполнять постинг операций не удастся.

Или я не прав?

[komar]

Извиняюсь, ответил по Акзапте. Надо что-то делать со структурой форума.

[Khodakovska]

Проблема в том что все в двух словах объяснить очень сложно, так что постараюсь все объяснить на выходных т. к .сейчас времени нет абсолютно но все действительно строиться на функциях CHANGECOMPANY и COMPANYNAME Я имела в виду что InterCompany это название задачи.

[rootadmin]

К вопросу об использовании измерений. Тут проблема в том, что еще надо и документы печатать от разных фирм. Так что тут или формы отчетов для каждой фирмы _жестко_ настраивать (что не совсем правильно) или менять структуру базы, что тоже достаточно трудоемко.
Так что, метдом исключения, похоже единственное решение вести несколько баз данных, сделав нужные таблици общими. И потихоньку накручивать механизмы автоматизации приемки-передачи товара от фирмы к фирме. А также заморачиваться с настройкой консолидации. Нда...

[Khodakovska]

Ок, постараюсь как-то объяснить что я сделала .Может быть не очень красивое решение но во всяком случае оно работает.
1. Создаем Purchase order в Сompany A --- в Company B автоматически создается Sales order.
a ) В company A создаем Vendor с именем и всеми данными company B .В таблице
vendor добавляем поле Сompany c TableRelation-Company ,Data Type –Text
b) В company B создаем Customer с именем и всеми данными company A В таблице
Сustomer добавляем поле Сompany c TableRelation-Company, Data Type –Text
c) В форме 50 Purchase Order создаем отдельную страницу например у меня это Intercompany где я помещаю следующие данные (естественно добавлены соответствующие поля в Purchase Header) : Sales order сделан для company….
Sales order номер …..
d ) )В форме 42 Sales Order создаем отдельную страницу Intercompany где я помещаю следующие данные (естественно добавлены соответствующие поля в Sales Header):
Cделан для компании ……
Для Purchase Order номер….
e) Создаем таблицу InterCompanyRefTable DataPerCompany-No
Type,SourceCompany,Source No.,Destination Company,Destination No
Я думаю здесь все понятно для чего
f) Следующее что я сделала создала отдельный CоdeUnit InterCompany где находяться все мои функции

И так создаем Purchase order в company A (Buy-from Vendor No –выбираем того у кого поле Соmpany –нужная нам Company B) в меню выбираем –Создать InterCompanyOrder
B CodeUnit создается функция СreateInterCompanySales order

Я думаю дальше все ясно ,что нужно сделать чтобы создать Sales order автоматически
В начале создаете Sales Header идете в табель Sales & Receivables Setup делаете CHANGECOMPANY(Vendor.Company)находите следующии номер Находите Customer
в Company B у которого Company = Company A и заполняете все оставшиеся поля как они заполняются в таблице Sales header .Понятно что VALIDATE применить не получиться Здесь лучше всего написать отдельный код. Например создать функцию
CreateDimansion где использовать codeunit DimenssionManagement где в свою очередь создать функию UpdateDocDefaultDimInterCompany куда следует добавить параметр txtInterCompany
Обязательно заполнить поля в c) и d)
C помощью таблицы InterCompanyRefTable создаем Sales line……

Думаю, как делать Post всех документов уже легко догадаться --- c) и d)…..
Здесь я не стала конечно переписывать код как в случае с Sales header и Sales line а сделала все гораздо проще хоть и там можно было сделать все аналогично Если нужно продолжу описание следующий раз

2 Как из Sales Order автоматически создать Purchase Order + Sales Order я думаю тоже должно быть понятно

Вопросы ?????

[Grizzly]

Цитата:

Изначально опубликовано Khodakovska
Думаю, как делать Post всех документов уже легко догадаться --- c) и d)…..

Уважаемая Khodakovska! Напротив, очень легко было догадаться как создать записи в другой компании, но абсолютно непонятно как, не переписывая стандартные учетные процедуры, автоматически выполнить пост заказа в другой фирме. Поясню это подробней.

1) Когда мы находимся в компании А, то по умолчанию в любом коде при обращении к некоторой таблице Т мы обращаемся к данным компании А.

2) Т.ChangeCompany('Б') позволяет при обращении к таблице Т обратится к данным компании Б. Однако для всех остальных таблиц для которых эта функция не выполнялась мы по-прежнему будем обращаться к данным компании А.

3) Пусть при вызове учетной процедуры мы ей передали набор записей (в нашем случае заказы), которые нужно учесть в компании Б. Но стандартная учетная процедура обращается еще и к другим таблицам, доступ к данным которых не перенаправлен. А так как ни о какой функциональности interCompany стандартная учетная процедура не знает, то открывает их в текущей компании А. И результаты пишет тоже в компанию А.

А описанное Вами решение может работать только если:
1) или будут переписаны все учетные процедуры с учетом "InterCompany", что не очень интересно
2) или Вы знаете некоторый технический прием для того, чтобы находясь в компании А все таблицы по умолчанию открывать в компании Б.

Именно это ключевой момент, а о нем Вы, к сожалению, как раз и не написали

[Khodakovska]

Цитата:

1) или будут переписаны все учетные процедуры с учетом "InterCompany", что не очень интересно

Для создания Sales order в компании А я так и сделала но для Post документов этого делать конечно не стоит т.к. придется почти весь Hави переписывать

Создается таблица например UpdateDoc DataPerCompany-No когда я делаю Poste Sales order в компании B я в тоже время записываю в компанию A в таблицу UpdateDoc номер
моего Purchase order в компании А и естественно тип документа.
Создаем функцию которая при открытии любой формы в компании А например Order
Posted Invoices начинает выполняться или создаем отдельное меню UpdateIntercompany Что должна сделать эта функция?
Прокрутить таблицу UpdateDoc
1 В таблице Purchase line выполнитьValidate Qty.to Receive тк Qty.to Receive должно быть таким же как Qty shipped в таблице Sales line компании В
2 Run Code Unit 90 c параметром recUpdateDoc.DocNr

Я думаю не нужно подробно рассказывать как это делать и так должно быть все понятно
Все необходимые связи есть с)d) + использование функций Сhangecompany .

Я не говорила что решение красивое но во всяком случае все работает Программа прошла тесты в Бельгии и Голландии. Всем понравилась т. к. раньше приходилось слать друг другу факсы.

[Grizzly]

Т.е. если я правильно понял, находясь в некоторой компании А, мы создаем, но НЕ УЧИТЫВАЕМ документы в компании Б, а вместо этого записываем в некоторую общую таблицу UpdateDoc указание на то, что документ в компании Б требует учета. С другой стороны, от имени пользователей, работающих в компании Б, по некоторому событию (в данном случае открытие формы) система проверяет в таблице UpdateDoc наличие указаний и учитывает нужные документы.

Цитата:

Я не говорила что решение красивое но во всяком случае все работает

По-моему, нормальное решение У нас в компании взаимодействие между учетной и биллинговой системами организовано подобным образом. И тоже пока проблем не было