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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 05.10.2011, 18:19   #1  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,846 / 2372 (87) +++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Ошибки в русских накладных, фактурах итп.
Дамы и господа, многих уже достали ошибки в счетах, фактурах и т.д, которые кочуют из версии в версию. Хотелось бы отлить этакую серебряную пулю для менеджера продукта в Москве (О. Дмитриева, не так ли?), и сделать суммарный запрос в сервисную систему со всеми известными ошибками.

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

Последний раз редактировалось EVGL; 02.11.2011 в 14:15.
За это сообщение автора поблагодарили: Ivanhoe (5), Kabardian (3), Cathome (1), gl00mie (5).
Старый 05.10.2011, 18:32   #2  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,505 / 4772 (165) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Я все-таки уточню, что главной проблемой будет не пофиксить, а зарегестрировать в поддержке. Ты заметил что на форуме часто появляются загадочные личности (например Ich@Ru) и после каждого описания ошибки, спрашивают - зарегистрированы ли они в поддержке? Как я понимаю, проблема в том, что без ссылки на запрос, разработчикам и менеджерам продукта просто не дадут зачекаутить классы и отчеты на изменение. Соответственно - задача не в том чтобы перечислить баги, а в том чтобы дать им описание подходящее для поддержки (то есть - разжеванное и переведенное на английский).
Старый 05.10.2011, 18:34   #3  
twilight is offline
twilight
MCTS
MCBMSS
 
724 / 141 (6) +++++
Регистрация: 17.10.2004
Адрес: Москва
Цитата:
Сообщение от EVGL Посмотреть сообщение
[*]настройка "Внешнее описание номенклатуры" игнорируется.
Вроде бы, не игнорируется. У меня внешнее описание выводилось.
__________________
I could tell you, but then I would have to bill you.
Старый 05.10.2011, 18:36   #4  
twilight is offline
twilight
MCTS
MCBMSS
 
724 / 141 (6) +++++
Регистрация: 17.10.2004
Адрес: Москва
Цитата:
Сообщение от fed Посмотреть сообщение
не содержат город банка
Кстати, город банка из какого поля должен подставляться? Из города в адресе или из локализованного поля "Местоположение"?
__________________
I could tell you, but then I would have to bill you.
Старый 05.10.2011, 18:41   #5  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,846 / 2372 (87) +++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от twilight Посмотреть сообщение
Кстати, город банка из какого поля должен подставляться? Из города в адресе или из локализованного поля "Местоположение"?
X++:
    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).
Старый 05.10.2011, 18:43   #6  
twilight is offline
twilight
MCTS
MCBMSS
 
724 / 141 (6) +++++
Регистрация: 17.10.2004
Адрес: Москва
1. Если не заполнено сокращенное наименование частей, то не надо выводить запятую после сокращенного наименования единиц в заголовке таблицы.
2. Если все номенклатуры относятся к типу Услуга, то в полях грузоотправитель и грузополучатель в счет-фактуре должен ставиться прочерк.
__________________
I could tell you, but then I would have to bill you.
За это сообщение автора поблагодарили: EVGL (1).
Старый 05.10.2011, 18:44   #7  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,846 / 2372 (87) +++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от twilight Посмотреть сообщение
Вроде бы, не игнорируется. У меня внешнее описание выводилось.
Отнюдь. В накладной всегда внешнее описание склеивается с внутренним, т.е. режим "Перезаписать" не работет. Более того, в коде этот параметр даже и не опрашивается. Опрашивается параметр для кода номенклатуры.
Старый 05.10.2011, 18:53   #8  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,233 / 2130 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Некоторые документы используют нестандартный отчет, а вывод в шаблон Excel / Word (например, ТН-ка)
Стандартное управление печатью для них тоже не работает.
Старый 05.10.2011, 18:55   #9  
lvan is offline
lvan
Участник
Аватар для lvan
Лучший по профессии 2014
 
788 / 66 (4) ++++
Регистрация: 15.04.2011
Записей в блоге: 1
Цитата:
Сообщение от EVGL Посмотреть сообщение
О. Дмитриева, не так ли?
Светлана
Старый 05.10.2011, 18:57   #10  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,846 / 2372 (87) +++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от fed Посмотреть сообщение
Я все-таки уточню, что главной проблемой будет не пофиксить, а зарегестрировать в поддержке. Ты заметил что на форуме часто появляются загадочные личности (например Ich@Ru) и после каждого описания ошибки, спрашивают - зарегистрированы ли они в поддержке? Как я понимаю, проблема в том, что без ссылки на запрос, разработчикам и менеджерам продукта просто не дадут зачекаутить классы и отчеты на изменение. Соответственно - задача не в том чтобы перечислить баги, а в том чтобы дать им описание подходящее для поддержки (то есть - разжеванное и переведенное на английский).
Да. Я возьму на себя эту титаническую работу. Более того, в случае неудовлетворительной работы поддержки я выложу в этой теме в отрытый доступ особенные перлы из корреспонденции с Microsoft. Считайте это официальным предупреждением (без обид, господин Р-н alias Ich@Ru, от тебя как раз всегда исходил конструктив).
За это сообщение автора поблагодарили: mazzy (5), AlGol (2), fed (5), Logger (0).
Старый 05.10.2011, 19:02   #11  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,846 / 2372 (87) +++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от Logger Посмотреть сообщение
Некоторые документы используют нестандартный отчет, а вывод в шаблон Excel / Word (например, ТН-ка)
Стандартное управление печатью для них тоже не работает.
Да. Я сознательно оставил это за скобками. Очевидным решением будет открыть сразу несколько окон с Excel, но от этого будет только хуже. Прямой печати на принтер все равно нет, а пользователю придется работать тогда сразу в нескольких окнах.
Старый 05.10.2011, 20:34   #12  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,056 / 2098 (78) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
1. Может, стоит все текстовые графы явно хранить в таблице накладной / фактуры (как в международной версии?), а то реквизиты берутся всегда текущие, что не есть хорошо.
2. В фактуре очень бы хотелось видеть информацию о платежках.
3. В накладной количество мест считается от какого-то поля в карточке товара (количество в упаковке что ли). Странно это
4. В идеале бы сделать возможность в авансовой фактуре выводить полноценный список товаров, а не в одно поле всё записывать.

В остальном польностью поддерживаю EVGL.
P.S. осенью МС собирает партнеров на "совет" - можно попробовать и там это повторить.
__________________
Ivanhoe as is..
За это сообщение автора поблагодарили: EVGL (2), someOne (2).
Старый 05.10.2011, 20:48   #13  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,233 / 2130 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Есть еще одна неприятная бага. Не связанная напрямую с печатью, но влияющая на печать (причем ошибка похоже не только в локализации).

Попробую быть краток :
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
расщепляет строки по ГТД.
Для расщепления используются запросы :
X++:
        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 (2), gl00mie (7), someOne (2).
Старый 05.10.2011, 21:21   #14  
Pustik is offline
Pustik
Участник
 
794 / 352 (13) ++++++
Регистрация: 04.06.2004
Цитата:
Сообщение от Logger Посмотреть сообщение
из-за этого возможна ситуация, когда номера накладных, даты и номера заказов совпадают, что приводит к перепутыванию строчек разных накладных.

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

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

Последний раз редактировалось Pustik; 05.10.2011 в 21:38.
За это сообщение автора поблагодарили: Logger (3).
Старый 05.10.2011, 22:00   #15  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,233 / 2130 (78) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Pustik Посмотреть сообщение
...Старая известная бага, которая мешает наверное, практически ВСЕМ. Главное, что когда в прошлом году в августе, присутствовав на презентации новых модификаций AX2009, об этом напрямую спросили, ...
Так бы и написали - БОЯН !!!

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

Кстати, а вы как лечили ?
Старый 05.10.2011, 22:29   #16  
Pustik is offline
Pustik
Участник
 
794 / 352 (13) ++++++
Регистрация: 04.06.2004
Цитата:
Сообщение от Logger Посмотреть сообщение
Кстати, а вы как лечили ?
так же как и Вы:
Цитата:
Сообщение от Logger Посмотреть сообщение
Самым безопасным, простым и дешевым способом на мой взгляд было бы сделать поле CustInvoiceJour.InvoiceId уникальным, а для печати использовать свое кастомизированное поле. Так безопаснее. По крайней мере большинство кода с вышеописанными косяками при этом условии выполняется правильно. Косяк не проявляется.
Еще с лохматого 2003 года.

P.S. Спасибо, что упомянули о проблеме.
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
За это сообщение автора поблагодарили: someOne (1).
Старый 05.10.2011, 23:11   #17  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,984 / 3888 (187) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
  • поле К расчетно-платежному документу должно заполняться автоматически на основании сопоставлений. Если сопоставлений несколько, то должно выводиться несколько документов с датами через запятую.
  • все реквизиты для печати должны хранится в СФ и в накладной. Чтобы была возможность перепечти документов даже тогда, когда реквизиты изменены. в том числе подписанты
  • в СФ на предоплату не хранятся подписанты

и т.д. и т.п.

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

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

Цитата:
Сообщение от EVGL Посмотреть сообщение
в соответствии с русскими реалиями должен быть режим номер накладной = номер фактуры = номер ТТН
будь внимателен. тут можешь получить как с кроличьей лапкой.
не обязательно номер СФ совпадает с номером накладной и т.п.
например, авансовая СФ должна создаваться сама по себе, безо всякой накладной.

это надо переформулировать следующим образом: должен быть механизм наследования, контроля и отслеживания номеров СФ, созданных на основании накладной.
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
За это сообщение автора поблагодарили: EVGL (2).
Старый 05.10.2011, 23:18   #18  
mazzy is offline
mazzy
Administrator
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
28,984 / 3888 (187) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Logger Посмотреть сообщение
Что с этим делать - фиг знает.
Самым безопасным, простым и дешевым способом на мой взгляд было бы сделать поле CustInvoiceJour.InvoiceId уникальным, а для печати использовать свое кастомизированное поле. Так безопаснее. По крайней мере большинство кода с вышеописанными косяками при этом условии выполняется правильно. Косяк не проявляется.
нет-нет-нет.
ни в коем случае. Сейчас уникальность определяется 4мя полями
SalesId, InvoiceId, InvoiceDate, numberSequenceGroup

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

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

нельзя делать CustInvoiceJour.InvoiceId уникальным
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 05.10.2011, 23:36   #19  
lvan is offline
lvan
Участник
Аватар для lvan
Лучший по профессии 2014
 
788 / 66 (4) ++++
Регистрация: 15.04.2011
Записей в блоге: 1
Цитата:
Сообщение от mazzy Посмотреть сообщение
прежде всего очень хочется, чтобы полностью переделали эту гребанную печатную форму с шейпами - убрали шейпы. из-за которых эти формы становится чудовищно сложно сопровождать и модифицировать. нигде в законодательстве не сказано, что "должны быть рамочки" "как в 1С"..
Гы, ты правда думаешь, что Microsoft будет что-то изменять в старой версии, тем более в отчетах, которых больше не будет?
Щас они на 100% загружены локализацией AX2012, и все ваши "хотелки" далеко задвинут.
А жаловаться на форумах - это лишь создаёт плохую репутацию, почитают люди и подумают, что аксапта говно и не купят, и останетесь вы без работы )))
А что ещё может подумать человек, когда заходит на форум и видит тему: "Ошибки в русских накладных, фактурах итп."
Пишите напрямую вендору о всех ваших проблемах, зачем изливать всё это тут?

Последний раз редактировалось lvan; 05.10.2011 в 23:46.
Старый 05.10.2011, 23:44   #20  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,846 / 2372 (87) +++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от mazzy Посмотреть сообщение
  • поле К расчетно-платежному документу должно заполняться автоматически на основании сопоставлений. Если сопоставлений несколько, то должно выводиться несколько документов с датами через запятую.
  • должен быть механизм наследования, контроля и отслеживания номеров СФ, созданных на основании накладной.
Справедливо! (не могу больше редактировать свой список вверху)

Цитата:
Сообщение от mazzy Посмотреть сообщение
  • все реквизиты для печати должны хранится в СФ и в накладной. Чтобы была возможность перепечти документов даже тогда, когда реквизиты изменены. в том числе подписанты
  • в СФ на предоплату не хранятся подписанты
Неоднозначно.
1) Нельзя быть святее папы (Microsoft), а названия компаний, собственное название и т.д. не хранятся в таблицах.
2) Ларец "должностные лица" пока не хочется открывать.

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

Последний раз редактировалось EVGL; 05.10.2011 в 23:47.
Теги
баг, локализация, накладная, ошибка, печатная форма, счет-фактура

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Уникальный индекс в журнале накладных поставщиков Starling DAX: Программирование 11 14.03.2011 17:02
Расхождение функционала журнала одобрения накладных. PavelM DAX: Функционал 4 22.12.2005 19:03
Ax3.0 SP3 CIS: Журнал накладных и российские договора (ошибка) mpa DAX: Функционал 2 11.10.2004 15:14
Как включить контроль изменений в журнале накладных ? NEO DAX: Функционал 0 17.06.2004 12:30
Одобрение накладных Swetik DAX: Функционал 1 24.11.2003 14:53
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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