Печать документов от разных юр. лиц из одной компании

[May]

Axapta 2.5 SP5

Интересует возможность реализации печати документов в рамках одной компании от разных юр. лиц: наименование, адрес, ИНН, банковские реквизиты.
В идеале, необходимо настроить разноску по приходу/расходу по счетам ГК в зависимости от выбранного юр. лица.
Подскажите, пожалуйста, наименее трудоемкий путь реализации данного механизма.

Заранее спасибо.

[komar]

Попробуйте так - совсем все таблицы общие, кроме реквизитов компании. То есть компаний в базе много, "начинка" у них через виртуальную компанию объединена, а таблицы с реквизитами отдельные.

[May]

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

[komar]

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

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

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

Вариант 1. Виртуальные компании.
Объединяются таблицы. Следовательно, нужно проанализировать около 2 тыс. таблиц и для каждой решить какой она будет - общей или частной. Потом создать нужные Table Collections. Работы немного. Единственное что нужно помнить, что разъединить таблицы проще, чем соединить в рабочей базе. Но проблему с нумераторами, если таблицы общие, придется решать за счет суффиксов/префиксов или разведением номеров по компаниям (у нас объединялись, например, строки Закупок/Заказов, а шапки - нет, а разводить пришлось нумераторы и строк и шапок).
Еще проблема - необходима лицензия "Компании неограничены", если компаний больше двух.

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

Навскидку это только часть проблем. В моей практике использовался всегда первый вариант. Его я считаю менее трудоемким.

[mazzy]

Цитата:

Изначально опубликовано Михаил Андреев
Вариант 1. Виртуальные компании.
Объединяются таблицы. Следовательно, нужно проанализировать около 2 тыс. таблиц и для каждой решить какой она будет - общей или частной. Потом создать нужные Table Collections. Работы немного.

Особенно, если пользоваться Visual morphXplorer'ом и перекрестными ссылками

Цитата:

Изначально опубликовано Михаил Андреев
Единственное что нужно помнить, что разъединить таблицы проще, чем соединить в рабочей базе.

Почему?

Цитата:

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

Почему проблема? Группа номерных серий вполне позволяет делать разные номера для СФ, накладных... Правда группы номерных серий не вставили в книгу покупок и продаж, а также в счет на оплату... Но если делается черно-белый учет и все "прочие" номерные серии идут в черный, то это вполне работоспособно.

Цитата:

Изначально опубликовано Михаил Андреев
Навскидку это только часть проблем. В моей практике использовался всегда первый вариант. Его я считаю менее трудоемким.

Ну... если только печать... И если не надо регистрировать историю в системе, то можно сделать и модификацию. В этом меня, например, Максим Горбунов убедил. Получается действительно очень локальная и не вредная модификация. Но только для печати! Если нужно оставлять историю в системе, то, может быть, действительно стоит пойти путем Михаила Андреева.

[glibs]

Цитата:

Изначально опубликовано mazzy
...Группа номерных серий вполне позволяет делать разные номера для СФ, накладных...

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

А вот для М-15 сделали группы. Значит все не на столько уж запущено. Может и для фактур сделают?

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

Объясняю, почему в работающей базе (в которой уже есть данные и она запущена в рабочую эксплуатацию) разъединить проще, чем объединить.
Разъединение можно сделать простым экспортом нужной таблицы, а затем импортом в реальные компании, попутно удалив лишние записи в каждой компании. Как правило, это довольно легко: быстро находятся записи, не связанные ни с чем и удаляются. Осталось проверить, что суммарное количество записей в двух (или нескольких) компаниях сохранилось и все. Можно даже в реальной базе зайти в SQL Query и поправить DataAreaId (проблема может быть с номерами). Но экспорт-импорт надежнее, типа средство штатное.

А вот объединить.... Не помню уже точно, какие таблицы пришлось объединять, но проблема была в том, что появились неуникальные записи из-за одинакового нумератора, которые раньше различались только DataAreaId. А чтобы исправить номера в одной таблице, нужно их также поправить во всех, где этот номер встречается. Можно представить, сколько таблиц придется перелопатить, если объединять таблицу InventDim, например, а если LedgerTrans, то лучше вообще не браться

[mazzy]

Цитата:

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

И снова спасибо тебе добрый фей...
Блн, устарели мои познания в этой области. Да, ты прав.
Группы существуют для PackingSlip, invioce, но отсутствуют для Facture_Ru...
Блин, блин, блин. В смысле, учиться, учиться и еще раз учиться...
Спасибо.

[mazzy]

Цитата:

Изначально опубликовано Михаил Андреев
Разъединение можно сделать простым экспортом нужной таблицы, а затем ...

Ага... понял. Спасибо.

[May]

Цитата:

Изначально опубликовано mazzy

Ну... если только печать... И если не надо регистрировать историю в системе, то можно сделать и модификацию. В этом меня, например, Максим Горбунов убедил. Получается действительно очень локальная и не вредная модификация. Но только для печати!

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

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

Цитата:

Изначально опубликовано May
Можно немного по подробней о том, что сказал Максим Горбунов?

Проще спросить самого Максима Горбунова

[mazzy]

Он сейчас в полях.

[Maxim Gorbunov]

Вот и я. Прямо из полей

Да, модификация действительно не очень большая.

Во-первых, надо решить, каким способом Вы будете вести учет юридических лиц. Я пробовал два варианта: (1) юр. лица храняться непосредственно в таблице CompanyInfo со значением Key не равным 0 (это значение зарезервировано для основной компании) или (2) юр. лица храняться в отдельной таблице, напоминающей CompanyInfo по структуре. В 1 случае придется немного поправить методы на таблице CompanyInfo (например, insert и find). Во втором случае желательно сразу завести Map, объединящий CompanyInfo и таблицу для юр. лиц.

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

И, наконец, модификация печати. Печать всех документов, кроме счетов-фактур, устроена так, что сначала происходит подготовка данных, и только затем они передаются в отчет. Отвечают за это классы SalesReport* и PurchReport*. Собственно, их и надо "подкручивать". Даже скажу, что смотреть надо метод initCompanyData.

Со счетами-фактурами ситуация немного другая: там сбор данных ведется непосредственно в отчете. Смотрите executeSection у секции, связанной с FactureJour. В качестве подсказки: здесь очень поможет использование Map'а, если Вы решили хранить юр. лиц в другой таблице.

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

[glibs]

Цитата:

Изначально опубликовано Maxim Gorbunov
...а вот на "Заказы" видимо сил при локализации не хватило...

Макс, я вспоминил. По сути еще один "Confirmation" (по русски "Подтверждение") появиля в Аксапте раньше, чем в России появился Навижин. Локализацией тогда занималась одна широкоизвестная компания...

[May]

Спасибо, будем пробовать.