DAX 4.0 Чем обусловлено наличие двух разных таблиц CustTable и VendTable?

[mazzy]

Цитата:

Сообщение от Бигудь

Как минимум, чтобы не дублировать данные при попадании одного и того же юрика в обе позиции.

А с чего вы взяли что они будут дублироваться?
Вы опять опыт 1С привносите в Аксапту?

[mazzy]

Цитата:

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

Ну что же, добро пожаловать в ад -2009. Там появились таблицы DirPartyXXX - т.н. "глобальная адресная книга". Супер вещь! Для нашего клиента - концерна с отдельными заводами, обслуживающих одних и тех же клиентов, передающих заказы друг другу через Intercompany, функция незаменимая.

о, да...

[Ivanhoe]

Цитата:

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

просто Иванов И.В = ИЧП Иванов И.В
или вы приравниваете ООО и физическое лицо?

Блин, совсем мешанина "лицо", "контрагент"
Сущность поставщик != сущность Контрагент.
Сущность клиент != сущность Контрагент.

Еще раз: разберитесь с сущностями

ок, Глоссарий:
1. Лицо - Социально-правовая фигура - физическое или юридическое лицо.
(с) Словарь по экономике и финансам. Глоссарий.ру
не привычнее контрагент, но пусть будет Лицо.
2. Клиент - сущность в AX.
3. Поставщик - сущность в AX.

По мне, Клиент и Поставщик ссылаются на сущность Лицо. Не равны, а именно ссылаются.

Цитата:

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

С какой стати?
Как поставщик он использует одни реквизиты, как клиент он использует другие.
Например, для оплаты ему как поставщику требуется один банк,
а как клиент он платит с другого банка.

Как поставщик он имеет одни прайс-листы, скидки и договора
Как клиент он имеет совсем другие прайс-листы, скидки и договра.

Офис продаж имеет один адрес (поставщик для нас), а служба снабжения совсем другой (для нас клиент).

Причем если у нас большая организация, то скорее всего наш продажник не должен ничего знать о закупках.

Ребяты! Ну, елы-палы...

=)
Как я написал выше:

Цитата:

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

Я сознательно не уточнял "ряд реквизитов". Как минимум есть реквизиты, которые ОДИНАКОВЫЕ для Клиента и Поставщика. ИНН, КПП, название лица, дата регистрации и т.п.

Я не говорю что справочник должен быть один. Я говорю про "ряд реквизитов". Если банковские счета разные - пожалуйста. А если одинаковые - зачем дублировать? ИНН, КПП, Название - всегда одинаковые. Руководитель Лица - всегда один и тот же. Почему нет?

[mazzy]

Цитата:

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

По мне, Клиент и Поставщик ссылаются на сущность Лицо. Не равны, а именно ссылаются.

Цитата:

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

Я не говорю что справочник должен быть один. Я говорю про "ряд реквизитов". Если банковские счета разные - пожалуйста. А если одинаковые - зачем дублировать? ИНН, КПП

Готов согласиться.
Но разработчики аксапты не стали парится
может быть и правильно, поскольку общий "ряд реквизитов" существенно меньше необщих.

Опять же смотрите в ax2009.

Цитата:

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

Название - всегда одинаковые. Руководитель Лица - всегда один и тот же. Почему нет?

С какой стати Название то одинаковые?
Как клиент он может использовать Английское/Немецкое название, а как поставщик использовать название русскими буквами в транскрипции.

блин, одинаковый клиент/поставщик вовсе не означает что будет юр.лицо с одинаковыми реквизитами. У юр.лица бывают и филиалы, представительства...

[Ivanhoe]

Цитата:

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

Готов согласиться

спасибо.

Цитата:

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

Но разработчики аксапты не стали парится
может быть и правильно, поскольку общий "ряд реквизитов" существенно меньше необщих.

Вот это мне лично и не нравится

Цитата:

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

С какой стати Название то одинаковые?
Как клиент он может использовать Английское/Немецкое название, а как поставщик использовать название русскими буквами в транскрипции.

блин, одинаковый клиент/поставщик вовсе не означает что будет юр.лицо с одинаковыми реквизитами. У юр.лица бывают и филиалы, представительства...

Ну давайте введем несколько названий. Пусть "удобное" название будет разным. А "официальное" название - одно. Например, в бумажный договор название идет как в учредительных документах / паспорте и никак иначе. По крайней мере в РФ.

Про представительства и филиалы песнь отдельная... там свои нюансы, согласен.

[belugin]

Я думаю, что правильный ответ на вопрос - "так исторически сложилось".

Поставщик и Заказчик - роли некоторых юридических и физических лиц по отношению к данной организации.

Я думаю, что стоило бы разделить данные о юрлице и данные о том, каким оно является постащиком или заказчиком.

Я думаю, на определенном этапе развития платформы было проще и удобнее сделать 2 разных таблицы.

Возможно, в будущем это нормализуют.

[mazzy]

Цитата:

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

Возможно, в будущем это нормализуют.

А как бы ты предложил?
И насколько тебя устраивает то, что сделали в ax2009? что бы ты порекомендовал изменить в ax2009?

[sukhanchik]

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

[mazzy]

Цитата:

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

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

В Аксапте? RTFM и Longson
В клиенте установите поле "Код поставщика"... Далее по тексту.

[sukhanchik]

Все.. пятница, вечер ... Ну да - это я про отчеты совсем забыл. Вопрос снимаю.

[gl00mie]

Цитата:

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

А как бы ты предложил?

Наверно, a-la InventTable + InventTableModule. Но, мне кажется, надо будет много думать, прежде чем разделить атрибуты на "общие" и специфичные для клиента/поставщика.

[glibs]

Цитата:

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

...
Возможно, в будущем это нормализуют.
...

Вот уж не надо, пожалуйста.

Что за удивительная способность всю жизнь наступать на одни и те же грабли и не делать выводов?

Гоните нафиг из Микрософта этих горе-теоретиков, которые уже начали в последних версиях "оптимизировать" Аксапту.

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

Что касается справочника поставщиков и клиентов... это не поставщики и клиенты.

И вот это уже не особенность Аксапты. А норма учета.

Обратите внимание как в Аксапте называется поле с кодом клиента. Это счет клиента.

А теперь сравните с тем, как вас учитывает оператор сотовой связи, если вы купите у него две или более SIM-карточки. Или как вас учитывает банк, если вы откроете в нем два или более счетов. Они даже и не подумают заводить вас там в какой-то справочник. Они просто заведут под вас два или более счетов, и не будут по этому поводу париться. И считать вас по каждому из счетов будут отдельно. И будут абсолютно правы.

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

Да, с учетом "особенностей национального бухучета" это выглядит диковато. Уверен, что найдутся люди, которые возьмутся утверждать, что так делать нельзя. Однако это скорее проблема нашего менталитета, способная в некоторых случаях нам мешать. И как обычно реально в законодательстве запрета на такое не найти. Это чистой воды стереотип "особенностей национального бухучета".

[Ivanhoe]

Цитата:

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

Вот уж не надо, пожалуйста.
.И вот это уже не особенность Аксапты. А норма учета.
...
А теперь сравните с тем, как вас учитывает оператор сотовой связи, если вы купите у него две или более SIM-карточки.
Или как вас учитывает банк, если вы откроете в нем два или более счетов. Они даже и не подумают заводить вас там в какой-то справочник. Они просто заведут под вас два или более счетов, и не будут по этому поводу париться. И считать вас по каждому из счетов будут отдельно. И будут абсолютно правы.

Не соглашусь. Операторы часто ведут привязку к одному лицевому счету нескольких SIM. Если идет розничная продажа через агентов и часть данных записывается "от балды", понятно, порядка не будет. Но возможность есть.

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

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

[Raven Melancholic]

Кстати, вспомнилась программа курса "Международные принципы учета" в институте. Например, в Франции код клиента (поставщика и т.п.) это вообще один из счетов плана счетов. Причем, если даже один и тот же клиент используется в операциях разной направленности (а в финансовой отчетности эти направления бизнеса указываются отдельно), то даже один и тот же клиент будет иметь разные коды для разных направлений бизнеса. То есть, например, если один контрагент покупает наши унитазы и наши облигации, то с точки зрения учета это разные клиенты!
Тут даже не только с точки зрения нашего учета, но и с моей точки зрения диковато выглядит. Хорошо, что в Аксе модульные и финансовые операции разделены и профилями разноски можно рулить такие ситуации.

[glibs]

Цитата:

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

...
Операторы часто ведут привязку к одному лицевому счету нескольких SIM.
...

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

А еще на эту тему вспомнил ЖЭКи и счета за услуги ЖКХ. Там тоже лицевые счета. Даже если вы купите несколько квартир в одном доме, у вас на каждую квартиру будет отдельный лицевой счет.

Цитата:

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

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

На одном счете? Банковский счет начинается с номера балансового счета (банковского). Вам банк открыл депозитный и карточный счет с одинаковым номером?

[sukhanchik]

Цитата:

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

На одном счете? Банковский счет начинается с номера балансового счета (банковского). Вам банк открыл депозитный и карточный счет с одинаковым номером?

Не... тут как я понимаю речь идет о некоем "личном кабинете" пользователя, в котором присутствуют с одной стороны - все его счета и баланс по ним, а с другой стороны - присутствует общий (суммарный) баланс по всем счетам пользователя.
Такое, к примеру, есть у Мастер-банка

[Zodiak]

Цитата:

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

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

При таком подходе, по-моему, возникает ряд вопросов, затрагивающих области чуть дальше бухучета - маркетинг, например. Как в этом случае посмотреть обороты по клиенту целиком, по всем его счетам, чтобы дать ему скидку? Как понять, какими продуктами пользуется клиент, а какими нет, и привязать этот факт к его профилю? Заводить отдельную CRM-систему?

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

[slava09]

Цитата:

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

А как бы ты предложил?
И насколько тебя устраивает то, что сделали в ax2009? что бы ты порекомендовал изменить в ax2009?

Можно, например, добавить таблицу "Юр. лицо" и в каждом справочнике, элемент которого может ссылаться на юр.лицо, сделать поле для ссылки на таблицу юр. лиц.

[Ivanhoe]

Цитата:

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

Не... тут как я понимаю речь идет о некоем "личном кабинете" пользователя, в котором присутствуют с одной стороны - все его счета и баланс по ним, а с другой стороны - присутствует общий (суммарный) баланс по всем счетам пользователя.
Такое, к примеру, есть у Мастер-банка

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

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

[mazzy]

Цитата:

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

Можно, например, добавить таблицу "Юр. лицо" и в каждом справочнике, элемент которого может ссылаться на юр.лицо, сделать поле для ссылки на таблицу юр. лиц.

а физ.лица в отдельной?