|
30.12.2011, 16:41 | #1 |
NavAx
|
А что делать с пакетниками, кторые разносят документы? Они вроде как не пользователи. Такую мину подложили.
|
|
|
За это сообщение автора поблагодарили: Pustik (5). |
30.12.2011, 17:07 | #2 |
Участник
|
Цитата:
Только в ядре на RU7 у нас аосы не всегда своевременно кеши синхронизируют. Похоже там тоже не все гладко. |
|
30.12.2011, 23:58 | #4 |
MCTS
|
На самом деле курсы не так страшны, как их малюют.
На Х++ кешируются загруженные курсы для определенной даты. Соответственно если в компании не увлекаются постоянным редактированием уже загруженных курсов, все работает стабильно. При загрузке курса на новую дату, он автоматом добавляется в кеш при разноске первой валютной операции на эту дату. Для тех редких клиентов, которые все-таки любят поиграться с уже созданными курсами, приходилось переделывать механизм кеширования таким образом, чтобы он работал только в рамках текущей транзакции. Алгоритм был приблизительно такой: Если транзакции нет - кеширование не работает. Если транзакция есть - выбирается запись из кеша. Если кеша нет, чтение из базы и сохранение в кеш. Если кеш есть - свяряются идентификаторы текущей транзакции и записи в кеше. Если совпадают - используется закешированный курс. Если не совпадают - кеш обновляется и сохраняется с идентификатором текущей транзакции. На производительность системы при разноске документов доработка практически не повлияла. И глюки с кешем пропали.
__________________
Dynamics AX Experience |
|
|
За это сообщение автора поблагодарили: Pustik (3), Logger (3). |
25.01.2012, 20:49 | #5 |
Banned
|
Коллеги из российского офиса подбросили материал.
Чтобы показать код валюты в новом счете-фактуре, надо заполнить ссылку на код из ОКВ в справочнике валют. Из серии "хотели как лучше": предлагается сначала этот код занести в список внешних кодов, но тут возникает интересный момент: не секрет, что что у нас может быть сразу несколько долларов и евро. Условные, не условные, очень условные и т.п. Так вот справочник внешних кодов не позволяет заносить в него более одного раза один и тот же код, скажем, 840. Приплыли. Чтобы справиться с этим, надо заводить внешние коды каждый раз под разными разрезами или выбросить из ключа таблицы внешних кодов уникальность. Последний раз редактировалось EVGL; 25.01.2012 в 21:03. |
|
09.04.2013, 20:06 | #6 |
Banned
|
Вот еще комментарий: форма создания новых продуктов и/или товаров - это форменное издевательство над пользователями.
Начать с того, что форму нормализовали. Вместо 5 таблиц их стало X знает сколько. При этом пользователю предоставили возможность воспользоваться шаблоном, чтобы не забивать по 100 полей. Только вот в шаблон попадает горстка записей - сам InventTable да EcoRes-как его там. Настройки кратности, склады, зоны хранения, настройки планирования - все это осталось за кадром. Все это надо заполнять заново - настоящее минное поле при работе с новой номенклатурой - 60 мест, чтобы совершить ошибку. Теперь обращу внимание на возможность создания новой номенклатуры из прямо из "EcoResProductPerCompanyListPage" при включенном счетчике номеров: Не обращали внимание, как заботливо система подставляет номер товара в имя товара и в поисковое имя? Перезаписываем имя - поисковое остается тем же номером. Прыгаем в поисковое поле, стираем вручную, сами удаляем пробелы. А теперь обратим внимание на имя в текущей компании, которое осталось справа: там теперь надо сделать все то же самое. Это насколько надо быть криворуким и бестолковым, не побоюсь этого слова, чтобы так запрограммировать примитивнейшую форму? Какой-то беспредел. |
|
07.03.2017, 19:44 | #7 |
Banned
|
Цитата:
Сообщение от EVGL
... в шаблон попадает горстка записей - сам InventTable да EcoRes-как его там. Настройки кратности, склады, зоны хранения, настройки планирования - все это осталось за кадром. Все это надо заполнять заново - настоящее минное поле при работе с новой номенклатурой - 60 мест, чтобы совершить ошибку.
... Не обращали внимание, как заботливо система подставляет номер товара в имя товара и в поисковое имя? Перезаписываем имя - поисковое остается тем же номером. Прыгаем в поисковое поле, стираем вручную, сами удаляем пробелы. А теперь обратим внимание на имя в текущей компании, которое осталось справа: там теперь надо сделать все то же самое. Настройки кратности для сайтов и настройки кратности по умолчанию для всего продукта слились в одну форму со сквозным приоритетом. И так и не были включены в структуру шаблона. И проклянул менеджер по продукту систему, чтобы пользователь тяжко трудился над ней всю свою жизнь из-за количества, которое подставляет система по умолчанию. |
|
07.03.2017, 23:31 | #8 |
Участник
|
|
|
26.04.2013, 18:14 | #9 |
Banned
|
Форма маршрута
Позвольте продолжить и прокомментировать форму маршрутов в AX2012 R2. По качеству исполнения можно предположить, что делала та же группа, что и форму для продуктов.
Начнем с того, что в группе ресурсов можно указать категории и массу других параметров по умолчанию. Посмотрим, как они взаимосвязаны с другими элементами приложения. Раньше отдельные ресурсы создавались из группы, в этот момент категории и пр. копировались из группы в ресурс. Теперь эти две сущности, по сути, независимы. Можно было бы предположить, что значения по умолчанию копируются при первом присоединении ресурса к группе, но это не так. Для чего же нужна категория в группе ресурсов? Попробуем выбрать в маршруте группу ресурсов в качестве Requirement: Заметим, что при использовании мыши для выбора группы надо принудительно нажать Tab на клавиатуре или куда-нибудь кликнуть, ибо источники данных в системе не согласованы, что приводит к ошибке "Введите Requirement". Система спрашивает, нужно ли скопировать значения по умолчанию в строку маршрута. Ага! Налицо явное улучшение по сравнению с AX2009, в которой копирование происходило только один раз при RecId == 0. Говорим "да"... хм, ничего не происходит. Оказывается, что, несмотря на подтверждающее диалоговое окно, копируются только настройки ресурса, а не группы ресурсов. В то же время, стратегия поиска свободных ресурсов подразумевает, что в маршруте указываются только характеристики и возможности ресурсов, а не их конкретные номера. Получается, что все поля - скорость, категории, все остальное - надо вводить в таком сценарии вручную. Кто-нибудь может проследить логику? |
|
30.04.2013, 12:37 | #10 |
Участник
|
Цитата:
А вот обновит ли система настройки в маршруте конкретного ПЗ когда при планировании будет выбран другой ресурс - это вопрос. Я не проверял, но думаю, что нет. |
|
30.04.2013, 12:45 | #11 |
Участник
|
Вообще как по мне вопрос только в категориях. Если при планировании время выполнения должно зависеть от конкретного ресурса, то для этого можно использовать Formula = Capacity и указать в настройках ресурса его мощность.
А с категориями вообще все не очевидно. Если у нас на одной операции задействовано несколько рабочих центров (не параллельные операции, а именно одна операция на 2-х ресурсах), то не понятно из какого из них нужно использовать эти самые категории. |
|
30.04.2013, 13:13 | #12 |
Banned
|
Думаю, что не обновит. По крайней мере, раньше не обновляла. И центры затрат, боюсь, не обновит, если Manufacturing Execution не используем.
|
|
23.05.2014, 01:10 | #13 |
Участник
|
А мне очень понравилась реализация структуры классов
ProjStatusUpd* Сразу видно, что разработчик - просто гений объектно-ориентированного программирования! Столько наследников!! Какая мысль!!! |
|
23.05.2014, 11:19 | #14 |
Участник
|
|
|
10.03.2017, 21:57 | #15 |
Участник
|
Очень долго объяснять.
Попробуйте дать себе ответ на вопрос чем отличаются эти классы друг от друга. А после этого подумайте о том, для чего вообще придумано ООП. О повторном использовании кода... О возможном изменении поведения при добавлении например нового статуса... В общем, много о чем можно подумать, глядя на этот гениальный образец использования ООП. |
|
11.03.2017, 07:53 | #16 |
Участник
|
__________________
// no comments |
|
11.03.2017, 09:20 | #17 |
Участник
|
|
|
Теги |
gab, virtual company, виртуальные компании, глобальная адресная книга |
|
Похожие темы | ||||
Тема | Ответов | |||
Работа с длительными операциями | 2 | |||
Lookupы при большом количестве записей выводимой таблицы | 9 |
|