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

[Alexius]

Цитата:

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

Сейчас уникальность определяется 4мя полями
SalesId, InvoiceId, InvoiceDate, numberSequenceGroup

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

Цитата:

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

нельзя делать CustInvoiceJour.InvoiceId уникальным

Я за уникальность этого поля и создание отдельного поля для печатных форм по аналогии с документами по поставщикам и фактурам.

PS. Для 2012 это скорее всего будет не актуально.

[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;
}

[Pustik]

Полностью присоединяюсь к Alexius, Logger хотя бы потому, что это устраивает и налоговую, и пользователей, и программистов(когда им нужно найти ошибку, допущенную пользователем). А добавленное поле и вывод его на печать это (на мой взгляд) не плохое И НЕ СЛОЖНОЕ решение. В чем может быть беда? Кто объяснит интересно будет услышать?

[mazzy]

часть обсуждения выделена в отдельную ветку
Кто каким образом делает "тонкую настройку" печатных форм (СФ, накладные и т.п.) под конкретного клиента?

[Ivanhoe]

EVGL, удалось составить некий конкретный перечень замечаний? Хочу включить их в рассмотрение на предстоящей партнерской встрече по локализации.

[EVGL]

Нет еще, на следующей неделе сделаю. Добавилось еще пунктов. Самое вопиющее - в акте на услуги нет строк.

[Ivanhoe]

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

[EVGL]

Обновил список в начале темы. Надеюсь, он окончательный.

[EVGL]

Ну что же, запрос 111102546177977 ушел в Microsoft. Затаим дыхание.

Цитата:

Hello,

We have compiled a list of the most annoying ‘features’ in Russian invoices, factures, bills of lading etc. Please understand I cannot split the list into 17 separate errors: managing so many requests would be an administrative nightmare. All the issues listed are discovered on the latest Rollup 7 with the Eastern European layer.
The list uses the following notation:
(-) The report does not abide by the Russian law or it leaves parts of the governmentally approved layout empty.
(+) The report ignores some standard AX settings. The report gets less flexible and difficult to use without modifications.
(*) The implementation of the report ignores common accounting praxis in Russia.

1-) The bank connection in all the documents (invoice, facture, invoice for payment, bill of lading, acceptance/service act) is corrupt: spaces are missing, the text field is too short and cut off, the bank city is missing, our INN number is missing. An example of a correct bank connection is provided, see p.18.
A code snippet dealing with this problem is provided in the attachment.

2+) All the 5 documents ignore the payment mode in ‘our bank account’. Regardless of the payment mode the reports show the default bank account from the company information, which is not always correct.

3-) Invoices and bills of lading exhibit a unit code (“t”) instead of the unit text (for example, “тонн”) in the customer language in the fields ‘Total net weight’ and ‘Total gross weight’.

4-) The so-called KPP number must be taken from the consignee in the facture report instead of the primary customer (if the consignee and the customer are separate legal entities).

5+) The management of the consignors and consignees is failed: there is no default consignor in the customer record. Each time the sales specialist have to select it from a list on sales order creation. An even better idea would be to redesign the functionality and use the normal delivery addresses instead of a separate entry in the customer table.

6+) All 5 documents ignore the form setting ‘Print item dimensions’ (AR / Setup / Forms / Form setup)

7+) The form setting ‘External item description’ is ignored. There is no way to achieve the effect of the ‘Overwrite’ option. I.e. one cannot replace the internal item name by the external name in any of the 5 reports.

8+) Print management is not implemented for factures. As a result, it is not possible to print a copy of the facture automatically.

9-) One cannot switch between the ‘old’ and ‘new’ bill of lading formats. The ‘new’ one is used if an external transport company is delivering the goods. The ‘old’ one should be used with the EXW delivery term (the customer uses his own transport). Unfortunately, the hotfix KB2589594 assumes a global parameter for the whole company while it is needed to select the layout on the customer and/or delivery term level.

10*) With the warehouse management module active, our clients expect the number of pallets to be printed in the fields ‘Places’, ‘Total places’ on the invoice and bill of lading. The ‘Qty. in one place’ field should show the number of items on one pallet, respectively.
See a code snippet.

11-) The facture is created from lines of invoice(s). Invoices may have a rounding on the header level. The invoice report compensates for these rounding errors and distributes it over lines. The facture does not. As a result, a facture created 1:1 out of a single invoice may deviate in lines and total amounts from the invoice.

12*) The common praxis in Russia is to print an invoice, a facture and a bill of lading with same numbers for a single delivery. I.e. there must be a mode to inherit the facture and BoL numbers from the invoice.

13-) The ‘Bill of lading’ field on the invoice is always empty even though BoLs can be created automatically on invoice posting.

14+) Should the ‘Shortcut name for parts’ in the monetary unit declensions be empty, do not print the comma in the column headers of invoices and factures.

15-) If a facture consists only of service items, do not print the consignee, consignor names. Replace them with dashes.

16+) The payment reference in the facture report can be filled if there are some settlements for the invoice. Should the facture/invoice be reconciled with several payments, print their numbers and dates in a line separated with commas.

17*) The [service] acceptance act is useless: it doesn’t show any lines, only totals.
See a code snippet.

18-) The service acceptance act is designed badly with regards to long company names / bank connections: any name longer than 255 characters leads to an error in MS Word (‘string is too long…’). Split it into several field/bookmarks, one with the company name, another with the company address, bank account etc.