Ошибки в русских накладных, фактурах итп.

[mazzy]

• поле К расчетно-платежному документу должно заполняться автоматически на основании сопоставлений. Если сопоставлений несколько, то должно выводиться несколько документов с датами через запятую.
• все реквизиты для печати должны хранится в СФ и в накладной. Чтобы была возможность перепечти документов даже тогда, когда реквизиты изменены. в том числе подписанты
• в СФ на предоплату не хранятся подписанты

и т.д. и т.п.

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

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

Цитата:

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

в соответствии с русскими реалиями должен быть режим номер накладной = номер фактуры = номер ТТН

будь внимателен. тут можешь получить как с кроличьей лапкой.
не обязательно номер СФ совпадает с номером накладной и т.п.
например, авансовая СФ должна создаваться сама по себе, безо всякой накладной.

это надо переформулировать следующим образом: должен быть механизм наследования, контроля и отслеживания номеров СФ, созданных на основании накладной.

[lvan]

Цитата:

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

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

Гы, ты правда думаешь, что Microsoft будет что-то изменять в старой версии, тем более в отчетах, которых больше не будет?
Щас они на 100% загружены локализацией AX2012, и все ваши "хотелки" далеко задвинут.
А жаловаться на форумах - это лишь создаёт плохую репутацию, почитают люди и подумают, что аксапта говно и не купят, и останетесь вы без работы )))
А что ещё может подумать человек, когда заходит на форум и видит тему: "Ошибки в русских накладных, фактурах итп."
Пишите напрямую вендору о всех ваших проблемах, зачем изливать всё это тут?

[mazzy]

Цитата:

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

Гы, ты правда думаешь, что Microsoft будет что-то изменять в старой версии, тем более в отчетах, которых больше не будет?

Не имею права комментировать это. Извините.

[lvan]

Цитата:

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

Не имею права комментировать это. Извините.

Неужели в российской локализации сохранят старые отчеты?
лучше бы уж темплейты в екселе нарисовали ей богу

[EVGL]

Цитата:

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

• поле К расчетно-платежному документу должно заполняться автоматически на основании сопоставлений. Если сопоставлений несколько, то должно выводиться несколько документов с датами через запятую.
• должен быть механизм наследования, контроля и отслеживания номеров СФ, созданных на основании накладной.

Справедливо! (не могу больше редактировать свой список вверху)

Цитата:

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

• все реквизиты для печати должны хранится в СФ и в накладной. Чтобы была возможность перепечти документов даже тогда, когда реквизиты изменены. в том числе подписанты
• в СФ на предоплату не хранятся подписанты

Неоднозначно.
1) Нельзя быть святее папы (Microsoft), а названия компаний, собственное название и т.д. не хранятся в таблицах.
2) Ларец "должностные лица" пока не хочется открывать.

Что касается InvoiceId, придерживаюсь мнения Mazzy: лучше не наступать на грабли, не ловить колючих ежей и оставлять номер уникальным. Если говорить о моих клиентах, то точечки, черточки и невидимые символы их вполне удовлетворяют.

[mazzy]

Цитата:

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

(не могу больше редактировать свой список вверху)

Добавил к твоим правам модератора возможность модерировать раздел "DAX: Программирование".
редактируй на здоровье.

но технологически такие вещи лучше вести в своем блоге
http://axforum.info/forums/blog.php

[egorych]

Цитата:

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

Что касается InvoiceId, придерживаюсь мнения Mazzy: лучше не наступать на грабли, не ловить колючих ежей и оставлять номер уникальным. Если говорить о моих клиентах, то точечки, черточки и невидимые символы их вполне удовлетворяют.

У нас кол-во точечек, черточек и т.п. иногда доходит до 8 !!! Так что хотса что-нибудь более прозрачное, что-ли.

[Logger]

Цитата:

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

Что касается InvoiceId, придерживаюсь мнения Mazzy: лучше не наступать на грабли, не ловить колючих ежей и оставлять номер уникальным. Если говорить о моих клиентах, то точечки, черточки и невидимые символы их вполне удовлетворяют.

EVGL, MAZZY - но ведь по сути это вариант 1, предложенный мной :

Цитата:

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

Самым безопасным, простым и дешевым способом на мой взгляд было бы сделать поле CustInvoiceJour.InvoiceId уникальным, а для печати использовать свое кастомизированное поле. Так безопаснее. По крайней мере большинство кода с вышеописанными косяками при этом условии выполняется правильно. Косяк не проявляется.

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

То есть, вы хотите чтобы для пользователя номер выглядел неизменным !
Зачем же мучать себя и людей и ограничиваться полумерами ?

Не проще ли развести идентификатор на 2 :
1. внутренний служебный идентификатор (InvoiceId) - желательно уникальный.
2. внешний идентификатора для печати (для пользователя) - свое локализованное поле.

В фактурах так и сделано.
Внутренний ключ это пара : FactureId, Module
Внешний номер для печати : FactureExternalId

Всем удобно, никто не жалуется. Проблем с этим ни разу не встретили.

Или вы во что бы то ни стало хотите избежать модификаций ?
Чего их бояться-то

[EVGL]

Цитата:

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

EVGL, MAZZY - но ведь по сути это вариант 1, предложенный мной...
Или вы во что бы то ни стало хотите избежать модификаций ?

Все верно. Я боюсь другого: Microsoft классифицирует это как новое требование, отложит в долгий ящик и сделает лет через 5. Поэтому я стараюсь быть осторожен в своих желаниях.

[Logger]

Цитата:

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

Все верно. Я боюсь другого: Microsoft классифицирует это как новое требование, отложит в долгий ящик и сделает лет через 5. Поэтому я стараюсь быть осторожен в своих желаниях.

А, это да.
Соглашусь.

Надо требовать реальные вещи от людей.

Я вообще это обсуждение затеял чтобы определиться как лучше. Можно и вообще не регать - все равно понятно как самим исправлять.

[Pustik]

Цитата:

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

Справедливо! (не могу больше редактировать свой список вверху)
Неоднозначно.
1) Нельзя быть святее папы (Microsoft), а названия компаний, собственное название и т.д. не хранятся в таблицах.
2) Ларец "должностные лица" пока не хочется открывать.

Что касается InvoiceId, придерживаюсь мнения Mazzy: лучше не наступать на грабли, не ловить колючих ежей и оставлять номер уникальным. Если говорить о моих клиентах, то точечки, черточки и невидимые символы их вполне удовлетворяют.

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

[EVGL]

Цитата:

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

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

Как мило, что все мы наступаем на одни и те же заботливо расставленные мины. Предлагаю следующий код, сделано в Австрии:

//BP deviation documented
display str getPaymentInfo()
{
    Object              factureCalcAdj;
    RecordSortedList    rst;
    CustInvoiceJour     invoiceJour;
    CustTrans           custTrans, custTransPayment;
    CustSettlement      custSettlement;
    str                 txt, ret;
    date                d;

    if (classidget(caller) == classnum(FactureCalcAmountAdjustments_RU))
    {
        factureCalcAdj = caller;
        return factureCalcAdj.getPaymentInfo();
    }
    else
    {
        rst = factureJour.invoiceJourSortedList_CustVend();
        while (rst.next(invoiceJour))
        {
            custTrans = invoiceJour.custTrans();
            while select custSettlement
                where custSettlement.TransCompany   == custTrans.dataAreaId
                   && custSettlement.TransRecId     == custTrans.RecId
                   && custSettlement.AccountNum     == custTrans.AccountNum
            {
                while select custTransPayment
                    where custTransPayment.AccountNum   == custSettlement.OffsetAccountNum
                       && custTransPayment.Voucher      == custSettlement.OffsetTransVoucher
                {
                    txt += ((txt ? ', ' : '') + custTransPayment.Txt);
                    d    = max(d, custTransPayment.TransDate);
                }
            }
        }
        ret = strfmt("%1: %2 %3: %4",
                     element.txtInLanguage(literalStr("@SYS2060")), txt,
                     element.txtInLanguage(literalStr("@SYS77627")), d);
    }

    return ret;
}