AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 27.03.2008, 00:38   #1  
longson is offline
longson
Участник
 
231 / 49 (2) +++
Регистрация: 12.12.2006
Адрес: Москва
Поле "Оплатить до" в строке общего журнала
Добрый день,

Хотелось бы обсудить с вами по следующей теме

В общем журнале, в строке (форме LedgerJournalTrans) есть поле "Оплатить до" - (Due), которое инициализируется в случае, если в качестве типа счета выбираем Клиент или Поставщик, и для этого клиента или поставщика выбираем конкретный договор, значение этого поля будет равняться значению аналогичного поля в справочнике договоров, либо равняться "сегодня" если в справочнике договоров ничего не определено.

Вот кусочек кода из класса LedgerJournalEngine, который всю эту работу выполняет

X++:
void initFromRContractTable_RU(LedgerJournalTrans ledgerJournalTrans)
{
    RContractTable rContractTable;
    ;
    rContractTable = this.findRContractTable_RU(ledgerJournalTrans);
    if (! rContractTable)
        return;

    if (rContractTable.ContractPaymCode && ledgerJournalTrans.Invoice) // PaymTermId
    {
        this.findPayment(rContractTable.ContractPaymCode);
        ledgerJournalTrans.Due  = payment.due(ledgerJournalTrans.TransDate, rContractTable.RContractPaymDayId);
    }
    else
    {
        ledgerJournalTrans.Due = ledgerJournalTrans.TransDate;
    }
Вот у меня возникают несколько вопросов :
  1. Почему это поле есть только в одной стороне, т.е если мы выбираем клиента или поставщика не в Счет, а в Корр.счет, то ничего связанного с этим не будет происходить. Вообще нет аналогичного поля для корр.счета.
  2. По какой логике это поле должно принимать значение, которое определяется в справочнике договоров. Представим, что если в общем журнале хотим регистрировать оплаты от клиентов, тогда на мой взгляд целесообразнее если это поле всегда принимает значение СЕГОДНЯ. Потому что это значение после разноски будет в таблице CustTrans (VendTrans) и CustTransOpen (VendTransOpen). В этих таблицах, смысл этого поля, по-моему, только для накладной. Для оплаты оно не носит никакой дополнительной информации.
  3. Вообще для чего предназначено это поле в таблице LedgerJournalTrans ?
Я по своей работе собираюсь поменять код чтобы значение этого поля в общем журнале всегда принимает значение СЕГОДНЯ. Но возможно, какие - нибудь идеи по функционалам не учитываю или не знаю ?
Старый 27.03.2008, 11:15   #2  
twilight is offline
twilight
MCTS
MCBMSS
 
867 / 237 (9) ++++++
Регистрация: 17.10.2004
Адрес: Королёв
1. Зачем регистрировать оплаты от клиентов в общем журнале? По моему журнал платежей в модуле расчеты с клиентами гораздо удобнее для этой цели, ведь, в конце концов он специально и был создан для этой цели.
2. Я так думаю, что смысл может быть когда мы вводим остатки по клиентам через главный журнал, тогда можно указать дату, если нужно отслеживать сроки задолженности.
Старый 27.03.2008, 13:29   #3  
Atar is offline
Atar
Консультант
 
287 / 101 (4) +++++
Регистрация: 10.03.2006
Адрес: Москва
Цитата:
Сообщение от twilight Посмотреть сообщение
1. Зачем регистрировать оплаты от клиентов в общем журнале? По моему журнал платежей в модуле расчеты с клиентами гораздо удобнее для этой цели, ведь, в конце концов он специально и был создан для этой цели.
2. Я так думаю, что смысл может быть когда мы вводим остатки по клиентам через главный журнал, тогда можно указать дату, если нужно отслеживать сроки задолженности.
Немного дополню:
по 1 пункту: именно поэтому поле "оплатить до" реализовано только для счета, что в журнале платежей клиент указывается в счете.
И использовать для регистрации платежей надо именно журнал платежей, поскольку отличий между ним и общим журналом больше, чем одно поле. Если захотите использовать общий журнал, то наверняка придется еще много чего дописывать.

И не забывайте, что поле "оплатить до" необходимо скорее не для платежей (я, честно говоря, не знаю зачем оно в платежах), а для регистрации задолженности клиента.
Тов. twilight Вам как раз и намекает в п.2, что и эту функциональность общего журнала следует использовать лишь, например, для заливки начальных сальдо с указанием предельных дат оплат, но не для какой-то текущей деятельности.
Старый 27.03.2008, 14:36   #4  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Цитата:
Сообщение от longson
...
Почему это поле есть только в одной стороне, т.е если мы выбираем клиента или поставщика не в Счет, а в Корр.счет, то ничего связанного с этим не будет происходить. Вообще нет аналогичного поля для корр.счета.
...
Потому что Аксапта нормально работает, когда в проводках есть только один клиент или поставщик. Проблема обсуждалась ранее.

Раньше (в 3.0 и ранее) система не ругалась, если в проводке (имеется в виду ваучер) участвует несколько клиентов и поставщиков. Но потом из-за этого сносило крышу некоторой функциональности. В 4.0 такие возможности существенно ограничили.

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

Про скидки по оплате и сопоставление они тоже, видимо, не знали тогда.

Вообще правильный подход в таком случае регистрировать многострочные проводки. Тогда и Профиль разноски, и Оплатить до, и Cкидки по оплате, и Сопоставление, и Аналитики, и прочий функционал доступны и для дебетового счета, и для кредитового.
Цитата:
Сообщение от longson
...
По какой логике это поле должно принимать значение, которое определяется в справочнике договоров. Представим, что если в общем журнале хотим регистрировать оплаты от клиентов, тогда на мой взгляд целесообразнее если это поле всегда принимает значение СЕГОДНЯ. Потому что это значение после разноски будет в таблице CustTrans (VendTrans) и CustTransOpen (VendTransOpen). В этих таблицах, смысл этого поля, по-моему, только для накладной. Для оплаты оно не носит никакой дополнительной информации.
...
Ну тут вы не совсем правы. То, с какой датой Оплатить до попадет в VendTransOpen повлияет на то, с какой датой сформируется LedgerCov. А если вы знаете что это такое и с чем его едят, то дата Оплатить до в оплате для вас будет совсем не безразлична.

Тем не менее, обычно оплата действительно должна проходить с той же датой Оплатить до, что и дата проводки. Вам уже подсказали, что оплаты правильным будет регистрировать в специализированном журнале платежей поставщикам. В этом журнале дата Оплатить до не вынесена в интерфейс и в коде не инициализируется из договора (причем не только из договора, между прочим). Если же вы хотите оплаты разносить из общего журнала...
Цитата:
Сообщение от longson
...
Вообще для чего предназначено это поле в таблице LedgerJournalTrans ?

Я по своей работе собираюсь поменять код чтобы значение этого поля в общем журнале всегда принимает значение СЕГОДНЯ. Но возможно, какие - нибудь идеи по функционалам не учитываю или не знаю ?
...
Это поле предназначено для того, чтобы в общем журнале можно было разносить накладные поставщиков и клиентов.

Я смотрел только что в 4.0. Там мне удавалось создать ситуацию, когда Оплатить до не менялось (оставалось равным дате платежа) при вводе оплаты. Договоры, правда, не использовал специально.

А вообще там... ну в общем, я только что посмотрел специально буржуйскую версию. Там заполнение поля Оплатить до зависит от того, указан или не указан номер инвойса. Соответственно система различает оплату и накладную.

Я помню, что локализаторы надругались над Оплатить до в заказах и закупках. Чтобы печатать счета на оплату, чтоли. Возможно, что и журналам ГК досталось. Похоже, в буржуйской версии общий журнал работает корректно. А в локализованной... вот так.

Если будете делать, рекомендую стремиться к стандартам из буржуйской функциональности.
__________________
С уважением,
glibs®
За это сообщение автора поблагодарили: Atar (1).
Старый 28.03.2008, 12:34   #5  
longson is offline
longson
Участник
 
231 / 49 (2) +++
Регистрация: 12.12.2006
Адрес: Москва
Журнал платежей поставщиков и клиентов мы не используем, так как мы выгружаем банковские выписки с клиента банк - и в одной банковской выписке может быть и платежи клиентов, и платежи поставщикам, и прочие оплаты налоговые, и много прочее ...
Старый 28.03.2008, 12:47   #6  
Михаил Андреев is offline
Михаил Андреев
Участник
Компания АМАНД
Лучший по профессии 2009
 
1,284 / 239 (10) ++++++
Регистрация: 09.11.2001
Адрес: Химки, Московская область
Цитата:
Сообщение от longson Посмотреть сообщение
Журнал платежей поставщиков и клиентов мы не используем, так как мы выгружаем банковские выписки с клиента банк - и в одной банковской выписке может быть и платежи клиентов, и платежи поставщикам, и прочие оплаты налоговые, и много прочее ...
Тогда и смысла в поле "Оплатить до" большого нет
Вообще, посмотрите классы, которые занимаются импортом платёжек иностранных банков (эти классы видны в форме Способы оплаты при нажатии кнопки Настройка). Их необязательно импортировать в ОДИН журнал. Можно хоть в 10 , а потом пользоваться формой "Перенесённые платежи" для разноски.
__________________
Михаил Андреев
https://www.amand.ru
Старый 29.03.2008, 00:36   #7  
longson is offline
longson
Участник
 
231 / 49 (2) +++
Регистрация: 12.12.2006
Адрес: Москва
glibs: Интересно, в чем может быть проблема, если в одной проводке есть в обей стороне - клиент или поставщики ?

У нас именно AX 3.0 SP5. Поэтому технически такая возможность не ограничена, и действительно в очень многих проводках у нас так и есть.
Старый 29.03.2008, 14:38   #8  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Не могу найти обсуждение. Но суть в том, что отчеты по выверке ГК и модульных проводок завязываются на дату, номер ваучера и тип разноски. А если в ваучере будет несколько операций с типом Клиент или поставщик — отчет начинает работать неверно. Также проблемы возникают при использовании просмотра происхожденя ваучера ГК.

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

Если же финансовое планирование у вас организовано таки в другой системе, и вам нужно загружать именно платежи из клиент-банка... А вы пользуетесь стандартной функциональностью создания платежей или пишете свой импорт?
__________________
С уважением,
glibs®
Теги
ax3.0, ax4.0

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Ошибка: фантомное дублирующее поле типа "дата" в гриде belugin DAX: Программирование 8 14.06.2006 00:15
поле "Закрытие" в плане счетов KatyN DAX: Функционал 1 07.06.2006 15:53
поле "Документы к обновлению" в форме "Обработка закупки" sev DAX: Функционал 3 08.12.2005 17:21
Заказ. Форма "Разноска накладной"->Строки-> Поле "закрытие" ATimTim DAX: Функционал 2 30.11.2004 16:14
Журнал переноса->Строки->Поле "Количество" . Нужен "0" по умолчанию вместо ATimTim DAX: Функционал 5 26.06.2004 12:17
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 02:42.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.