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

[EVGL]

Дамы и господа, многих уже достали ошибки в счетах, фактурах и т.д, которые кочуют из версии в версию. Хотелось бы отлить этакую серебряную пулю для менеджера продукта в Москве (О. Дмитриева, не так ли?), и сделать суммарный запрос в сервисную систему со всеми известными ошибками.

Попробую начать:

• все банковские реквизиты выглядят отвратительно во всех документах: не содержат пробелов, обрезаются, не содержат город банка
• при определении "нашего" банка игнорируется способ оплаты
• в накладных в графах "итого вес" подставляется код ЕИ вместо текста ЕИ
• в счете-фактуре КПП берется с плательщика, а не с грузополучателя
• работать с грузополучателем невозможно, поскольку как минимум нет грузополучателя по умолчанию (как максимум - вся концепция неверна)
• все документы принципиально игнорируют настройку форм "Печать номенклатурных аналитик"
• настройка "Внешнее описание номенклатуры" игнорируется. Режима "Перезаписать" невозможно добиться никакими настройками.
• для счета-фактуры не предусмотрено "Управление печатью", и вывести более одной копии невозможно.
• если активировано управление складом, то в полях "кол-во мест" и "в одном месте" должно подставляться количество палет и количество штук в одной палете, соответственно
• фактура формируется из строк накладной. При наличии округления в заголовке накладной она и фактура расходятся на несколько копеек за счет того, что в накладной округление начинает пропорционально разбрасываться на строки.
• в соответствии с русскими реалиями должен быть режим номер накладной = номер фактуры = номер ТТН, т.е. должен быть механизм наследования, контроля и отслеживания номеров СФ, созданных на основании накладной
• в графе накладной "Транспортная накладная" никогда не выводится номер ТТН, хотя мог бы (в режиме генерации ТТН из журнала накладных)
• ...
• Если не заполнено сокращенное наименование частей валюты, то не надо выводить запятую после сокращенного наименования единиц в заголовке таблицы
• поле "К расчетно-платежному документу" должно заполняться автоматически на основании сопоставлений. Если сопоставлений несколько, то должно выводиться несколько документов с датами через запятую.
  ...
• акт на услуги нежизнеспособный: он не содержит строк
• акт на услуги составлен так, что вывод реалистичного адреса с реквизитами длиной в 300 символов вызывает ошибку "... is too long". Надо реквизиты делить на составные части: в отдельную ячейку выводить название компании, потом - адрес ит.д.

[fed]

Я все-таки уточню, что главной проблемой будет не пофиксить, а зарегестрировать в поддержке. Ты заметил что на форуме часто появляются загадочные личности (например Ich@Ru) и после каждого описания ошибки, спрашивают - зарегистрированы ли они в поддержке? Как я понимаю, проблема в том, что без ссылки на запрос, разработчикам и менеджерам продукта просто не дадут зачекаутить классы и отчеты на изменение. Соответственно - задача не в том чтобы перечислить баги, а в том чтобы дать им описание подходящее для поддержки (то есть - разжеванное и переведенное на английский).

[twilight]

Цитата:

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

[*]настройка "Внешнее описание номенклатуры" игнорируется.

Вроде бы, не игнорируется. У меня внешнее описание выводилось.

[twilight]

Цитата:

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

не содержат город банка

Кстати, город банка из какого поля должен подставляться? Из города в адресе или из локализованного поля "Местоположение"?

[EVGL]

Цитата:

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

Кстати, город банка из какого поля должен подставляться? Из города в адресе или из локализованного поля "Местоположение"?

    return ....
        (bankAccountTable.TownId_RU     ? SysLabel::labelId2String(literalstr(""), languageId)         + ' ' +
                                          AddressTown_RU::Find(bankAccountTable.CountryRegionId,
                                                               bankAccountTable.State,
                                                               bankAccountTable.County,
                                                               bankAccountTable.TownId_RU).fullName_RU()                                      + ' '  :
         bankAccountTable.City          ? bankAccountTable.City                                                                               + ' '  : "")

[twilight]

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

[EVGL]

Цитата:

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

Вроде бы, не игнорируется. У меня внешнее описание выводилось.

Отнюдь. В накладной всегда внешнее описание склеивается с внутренним, т.е. режим "Перезаписать" не работет. Более того, в коде этот параметр даже и не опрашивается. Опрашивается параметр для кода номенклатуры.

[Logger]

Некоторые документы используют нестандартный отчет, а вывод в шаблон Excel / Word (например, ТН-ка)
Стандартное управление печатью для них тоже не работает.

[lvan]

Цитата:

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

О. Дмитриева, не так ли?

Светлана

[EVGL]

Цитата:

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

Я все-таки уточню, что главной проблемой будет не пофиксить, а зарегестрировать в поддержке. Ты заметил что на форуме часто появляются загадочные личности (например Ich@Ru) и после каждого описания ошибки, спрашивают - зарегистрированы ли они в поддержке? Как я понимаю, проблема в том, что без ссылки на запрос, разработчикам и менеджерам продукта просто не дадут зачекаутить классы и отчеты на изменение. Соответственно - задача не в том чтобы перечислить баги, а в том чтобы дать им описание подходящее для поддержки (то есть - разжеванное и переведенное на английский).

Да. Я возьму на себя эту титаническую работу. Более того, в случае неудовлетворительной работы поддержки я выложу в этой теме в отрытый доступ особенные перлы из корреспонденции с Microsoft. Считайте это официальным предупреждением (без обид, господин Р-н alias Ich@Ru, от тебя как раз всегда исходил конструктив).

[EVGL]

Цитата:

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

Некоторые документы используют нестандартный отчет, а вывод в шаблон Excel / Word (например, ТН-ка)
Стандартное управление печатью для них тоже не работает.

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

[Ivanhoe]

1. Может, стоит все текстовые графы явно хранить в таблице накладной / фактуры (как в международной версии?), а то реквизиты берутся всегда текущие, что не есть хорошо.
2. В фактуре очень бы хотелось видеть информацию о платежках.
3. В накладной количество мест считается от какого-то поля в карточке товара (количество в упаковке что ли). Странно это
4. В идеале бы сделать возможность в авансовой фактуре выводить полноценный список товаров, а не в одно поле всё записывать.

В остальном польностью поддерживаю EVGL.
P.S. осенью МС собирает партнеров на "совет" - можно попробовать и там это повторить.

[Logger]

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

Попробую быть краток :
1. Связь между шапкой CustInvoiceJour и строками CustInvoiceTrans идет по странному Relation, в который входят поля :
SalesId
InvoiceId
InvoiceDate
numberSequenceGroup
но нет аналога поля VendInvoiceJour.InternalInvoiceId

из-за этого возможна ситуация, когда номера накладных, даты и номера заказов совпадают, что приводит к перепутыванию строчек разных накладных.

А это в свою очередь происходит из-за того, что :

2. Поле CustInvoiceJour.invoiceID является как составной частью первичного ключа таблички, так и номером документа, выводимым на печать.
На практике это крайне неудобно, так как нередко приходится исправлять ошибки в документах через кредит-ноту.

Например, выписали накладную по заказу. Заметили ошибку, сделали по заказу сторно через немедленное получение. Исправили документ, закатываем накладную по заказу заново. Клиент требует чтобы номер не менялся.
Что делать ?
Разрешаем дубликаты CustInvoiceJour.invoiceID и получаем все вышеописанные проблемы.

т.е. надо выделить поле - первичный ключ накладной, а-ля InventJournalTable.JournalId и использовать его для связки шапки и строк, но не для печати.

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

Со всеми вытекающими проблемами...

Навскидку :
4. Метод \Classes\FactureTransCreateCust_RU\createTrans
расщепляет строки по ГТД.
Для расщепления используются запросы :

        select sum(Qty) from inventTrans
            where inventTrans.InvoiceId     == custInvoiceTrans.InvoiceId       &&
                  inventTrans.DateFinancial == custInvoiceTrans.InvoiceDate     &&
                  inventTrans.InventTransId == custInvoiceTrans.InventTransId
        join InventGtdId_RU from inventDim
            group by InventGtdId_RU
            where inventDim.InventDimId     == inventTrans.InventDimId;

        while (qtyToAllocate && inventTrans)
        {
            select sum(Qty) from factureTransSum
                where factureTransSum.InventTransId   == custInvoiceTrans.InventTransId  &&
                      factureTransSum.InvoiceId       == custInvoiceTrans.InvoiceId      &&
                      factureTransSum.InvoiceDate     == custInvoiceTrans.InvoiceDate    &&
                      factureTransSum.InventGTDId     == inventDim.InventGtdId_RU        &&
                      factureTransSum.FactureLineType == FactureLineType_RU::InvoiceLine &&
                      factureTransSum.Module          == FactureModule_RU::Cust;

т.е. в качестве первичного ключа идентифицирующего шапку накладной используется связка
InvoiceId
InvoiceDate

Легко видеть что если по лоту у нас отгружается 2 ГТД-ки по 5 штук, то после сторнирования и проведения фактуры заново может получиться 1 ГТД-ка на 10 штук. т.е. 5 штук будет взято из правильной накладной и 5 из исправленной, а 2-я ГТД-ка вообще в фактуру не попадет.

5. Код
\Data Dictionary\Tables\InventTrans\Methods\qtyInvoiceSold
также закладывается только на InvoiceId
что приходит в конечном итоге к проблемам при вызове с формы
\Forms\SalesCopying\Methods\canClose
(копирование строк, создание кредит-нот с неверными количествами salesLine.QtyOrdered и.т.п.)

6. Также есть ряд мест в расчете налогов, в книгах покупок и продаж, где ваучер не используется.
\Classes\BookTransCalc_Sales_RU\appendGtd
\Classes\SalesCalcTax_Invoice\initCursor

Правда в 3-ке таких мест было больше.
В одном месте я как то видел просто фильтр по InvoiceId и все.

Повеселило...


P.S.

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

Можно еще добавить в строки CustInvoiceTrans, FactureTrans - ваучер и везде в запросах добавлять фильтры по нему. Работает корректно. Но поддерживать сложно, особенно с выходом сервис-паков. Хотя мы в итоге по этому пути и пошли. (Исторически так сложилось)

Надежды что это когда-нить исправят - уже нет, особенно с учетом того что в 2012-й все переколбасили, т.е. исправление будет актуально только для 2009-й версии.

[Pustik]

Цитата:

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

из-за этого возможна ситуация, когда номера накладных, даты и номера заказов совпадают, что приводит к перепутыванию строчек разных накладных.

А это в свою очередь происходит из-за того, что :

2. Поле CustInvoiceJour.invoiceID является как составной частью первичного ключа таблички, так и номером документа, выводимым на печать.
На практике это крайне неудобно, так как нередко приходится исправлять ошибки в документах через кредит-ноту.

Старая известная бага, которая мешает наверное, практически ВСЕМ. Главное, что когда в прошлом году в августе, присутствовав на презентации новых модификаций AX2009, об этом напрямую спросили, ответ был такой : "А что действительно номер счет-фактуры у Вас может повторяться?", Ответ - "Да!!!!!!, Если это сторно!!!", -"А почему??????", Ответ: -"Потому что так требуют налоговые органы." .
Зал засмеялся.

[Logger]

Цитата:

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

...Старая известная бага, которая мешает наверное, практически ВСЕМ. Главное, что когда в прошлом году в августе, присутствовав на презентации новых модификаций AX2009, об этом напрямую спросили, ...

Так бы и написали - БОЯН !!!

Интересно, а кто нить это регал в поддержке ? Чего говорят-то ?

Кстати, а вы как лечили ?

[Pustik]

Цитата:

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

Кстати, а вы как лечили ?

так же как и Вы:

Цитата:

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

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

Еще с лохматого 2003 года.

P.S. Спасибо, что упомянули о проблеме.

[mazzy]

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

и т.д. и т.п.

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

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

Цитата:

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

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

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

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

[mazzy]

Цитата:

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

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

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

InvoiceDate позволяет начинать нумерацию с 1 каждый новый год (как обычно этого хочет бухгалтерия)

numberSequenceGroup позволяет выписывать накладные с одинаковыми номерами из разных подрезделений или в разных точках продаж.

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

[lvan]

Цитата:

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

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

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

[EVGL]

Цитата:

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

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

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

Цитата:

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

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

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

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