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

[belugin]

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

[gl00mie]

Цитата:

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

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

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

[slava09]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

[glibs]

Цитата:

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

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

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

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

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

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

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

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

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

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

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

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

[Ivanhoe]

Цитата:

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

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

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

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

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

[Raven Melancholic]

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

[glibs]

Цитата:

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

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

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

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

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

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

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

[Zodiak]

Цитата:

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

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

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

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

[glibs]

Цитата:

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

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

Согласен. С управленческой т.з. возможность собрать все в кучу важна. С т.з. учета... уже написал.

Цитата:

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

...
Как в этом случае посмотреть обороты по клиенту целиком
...

В общем случае это будет "средняя температура по палате". Даже еще хуже. Подобного рода вопросы так тупо не решаются. В лучшем случае будет более сложный алгоритм, чаще экспертная оценка.

Цитата:

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

...
Заводить отдельную CRM-систему?
...

В том то и дело, что CRM в Аксапте есть.

Вот только я задумался по ходу дискуссии, почему там под клиентов и поставщиков заводятся отдельные ДО.

[sukhanchik]

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

[mazzy]

Цитата:

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

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

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

[sukhanchik]

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