Рыба новой товарно-транспортной накладной (ТТН)

[EVGL]

Цитата:

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

Стандартный Bill of lading в системе - это не CMR

Да, верно, я поторопился. Похож, но не то.

[Logger]

По-моему дискуссия ушла в другое русло.

Главный вопрос на котором хотелось бы акцентировать внимание :
1. Почему в Ax2009 используется схема подготовки обновлений, более сложная в обращении чем для 4-ки. Может быть вернуться к варианту 4-ки ?
2. После того как я выбрал только необходимые нам изменения по ТН-ке из обновления и собрал их в проект (размер получился порядка 6-8 мегов на весь xpo, вместо двух xpo по 50 мегов. итого разница более чем в 10 раз и объем сравним с объемом Xpo для 4-ки), то возникло ощущение что в стандартной поставке было много лишнего и те кто готовил обновление просто не стали утруждать себя в выделении необходимого. В результате установка патча по трудозатратам стала сравнима с накатом целого Rollup. Уверен что это неправильно и с этим надо что-то делать. Т.е. возможно надо оставить схему как для 2009-й, но просто тщательнее готовить обновление ?

P.S. Использование шаблона Word по моему мнению неприемлемо, так как невозможно использовать стандартные для всех отчетов в Аксапте настройки печати. Желательно было сделать стандартный Аксаптовский репорт. Обновление не дает возможности при обработке документа сразу отправить ТН-ку на печать, а тупо выплевывает её всегда на экран.
Также работа с офисными документами в Аксапте отвратительна. (Реально как неоднократно обсуждали на форуме, виной всему асинхронное взаимодействие с com объектами) Было бы здорово если бы удалось пофиксить ядро или найти другой способ безглючной работы с офисными документами из Аксапты. Использование макросов #StartSafeCall_RU и #EndSafeCall_RU снижает остроту проблемы и за это вам спасибо, но к сожалению это не решение проблемы.

[EVGL]

Цитата:

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

P.S. Использование шаблона Word по моему мнению неприемлемо, так как невозможно использовать стандартные для всех отчетов в Аксапте настройки печати. Желательно было сделать стандартный Аксаптовский репорт. Обновление не дает возможности при обработке документа сразу отправить ТН-ку на печать, а тупо выплевывает её всегда на экран.
Также работа с офисными документами в Аксапте отвратительна. (Реально как неоднократно обсуждали на форуме, виной всему асинхронное взаимодействие с com объектами) Было бы здорово если бы удалось пофиксить ядро или найти другой способ безглючной работы с офисными документами из Аксапты. Использование макросов #StartSafeCall_RU и #EndSafeCall_RU снижает остроту проблемы и за это вам спасибо, но к сожалению это не решение проблемы.

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

[Logger]

Цитата:

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

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

Можете кинуть ссылочку ?
Хотелось бы проверить.
Вы используете терминальные сервера в работе ?

[EVGL]

Цитата:

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

Можете кинуть ссылочку ?
Хотелось бы проверить.
Вы используете терминальные сервера в работе ?

К сожалению, человек, который этим занимался, сейчас в отпуске. Вернется - спрошу.
Да, проблема возникала только на терминальных серверах при пакетной печати ТТН.

[Maximin]

На мой непросвещенный взгляд, радикальное решение проблемы для взаимодействия с MS Office было бы переписывание его на использование CLR Runtime. По собственному опыту, это не занимает много времени. Другое дело, что это потребует значительного объема тестирования.
Доп. плюсом этого решения была бы "видимость" методов CLR объектов внутри редактора X++. Правда, я не совсем уверен в возможности красиво решить вопрос о работе с различными версиями офиса, но, насколько знаю, это всё же технически возможно, пусть и с помощью небольших костылей. В крайнем случае, это всегда можно прописать в технические требования системы.

По набору исправлений для новой ТТН - это вообще ни в какие ворота не лезет - пихать туда целиком весь merge еще с 3его хотфикса. Неужели вендор хотя бы для себя не может наладить нормальный репозитарий кода современными средствами (git, mercurial, да хоть TFS в конце концов) и вести несколько branches для выделения подобных патчей?

[Logger]

Цитата:

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

На мой непросвещенный взгляд, радикальное решение проблемы для взаимодействия с MS Office было бы переписывание его на использование CLR Runtime. По собственному опыту, это не занимает много времени.

По поводу не займет много времени - сильно сомневаюсь. Знаю людей, которые предприняли такие попытки - трудозатрат ушло много.
Одна из проблем - в куче мест объекты создаются через new, а не construct - приходится переделывать много лишнего кода. Также в ряде мест методы которые работали через com - валятся при вызовах через .Net
Причину определить не удалось пока.
В общем, есть подозрение что вы целиком сами всю эту работу не пробовали проделать. Или написали несколько фиксов для конкретных мест. Или вы смогли переделать все семейство классов по работе с Excel легко и быстро и исправить все места где они используются ?

Также переписывание через .Net предполагает что у вас будет стоять office2010.

[Удвой Покуров]

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

1. Спасибо, что на форуме отвечаете на вопросы
2. Будет возможность-пните криворучек

[belugin]

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

В результате, если хотфикс a модифицирует компонент b, и его же модифицировал ранее хотфикс c, то мы получаем оба хотфикса сразу.

И этот процесс идет каскадно.

Так как на приложении может как быть установлен хотфикс c так и не установлен. А обновление дожно производится автоматически.


Либо надо отказываться от какого-то из требований. Либо надо выпускать n вариантов одного и того же кода. Либо рефакторить аксапту в хвост и гриву, чтобы компоненты были поменьше.

Интересно, как бы уважаемый Удвой организовал такие обновления. Вот, допустим, у вас есть какая хотите система контроля версий. И вам надо выдать протестированный хотфикс с гарантией его установки на систему клиента на который могут быть уже установлены n других хотфиксов.

[tolstjak]

Добрый день, уважаемые.

Подскажите пожалуйста как в транспортной накладной для 4.0 решен вопрос вывода наименования груза в графе 3.
Мы (АХ 3.0) используем шаблон Word с именованными полями. Переменная для поля 3 формируется как сумма всех наименований + количество + ед.изм всех строк накладной. Когда в накладной много строк и их названия длинные, вываливается ошибка "Строка слишком длинная".
Как это проблема решена в 4.0 или что можете посоветовать?

Заранее благодарен

[gene]

Цитата:

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

Добрый день, уважаемые.

Подскажите пожалуйста как в транспортной накладной для 4.0 решен вопрос вывода наименования груза в графе 3.
Мы (АХ 3.0) используем шаблон Word с именованными полями. Переменная для поля 3 формируется как сумма всех наименований + количество + ед.изм всех строк накладной. Когда в накладной много строк и их названия длинные, вываливается ошибка "Строка слишком длинная".
Как это проблема решена в 4.0 или что можете посоветовать?

Заранее благодарен

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

[tolstjak]

Цитата:

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

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

Понятно. Получается, что мы пошли несколько дальше постановления и попытались автоматизировать заполнение накладной.
Пришлось сделать ниже второе именное поле и разбивать текст на несколько частей. Не нравится, то что Word не может переварить длину строки больше 254 знаков. Эти знаки он выводит в две строки, причем вторая не полностью заполненная. из-за чего получается следующая картина (при выравнивании по левому краю)
рррррррррррррррррррррррррррррррррррррррррррррррррррр
рррррррррррррррррррррррррррррррр
рррррррррррррррррррррррррррррррррррррррррррррррррррр
рррррррррррррррррррррррррррррррр

Как это можно победить?

[Сисой]

Цитата:

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

Добрый день, уважаемые.
Подскажите пожалуйста как в транспортной накладной для 4.0 решен вопрос вывода наименования груза в графе 3.
............

Толком никто не знает, что туда писать.
В 1С сделали так (можно и вручную вводить, естественно):

[Zabr]

Цитата:

Сообщение от Сисой

Толком никто не знает, что туда писать.

Наш главбух сказала, что достаточно печатать наименование товарной группы. Так и делаем: группируем строки накладной по товарным группам, и если их получается N, то печатаем через запятую N наименований групп, например: "Одежда,Обувь". То есть почти так, как делает Сисой.

[tolstjak]

Zabr : Спасибо. Это хорошая мысль.

Сисой: Спасибо.Спасибо.

[Logger]

Если уж вы взялись а кастомизации, то может быть проще привинтить обычный аксаптовский отчет (я выкладывал в этой теме).

У него таких проблем не будет.

[tolstjak]

Цитата:

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

Если уж вы взялись а кастомизации, то может быть проще привинтить обычный аксаптовский отчет (я выкладывал в этой теме).

У него таких проблем не будет.

В Ах 3.0 ваш проект просто не открывается. У нас тоже ввиде отчета.

[samolalex]

Цитата:

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

В Ах 3.0 ваш проект просто не открывается. У нас тоже ввиде отчета.

Недавно возникла потребность реализовать данный документ в виде аксаптовского отчета (в Axapta 3). До этого все работало посредством COM и выводилось в dot-файл.
Но, в силу возникновения проблем с печатью на удаленном компьютере, пришлось прибегнуть к использованию стандартного отчета.
Используя отчет ТН, размещенный Logger'ом для Ax2009 в этой теме (здесь), я переделал его для Axapta3, немного доработав дизайн и добавив нужные дисплейные поля.
Так что, может кому-то пригодится данный отчет в Axapta3, несмотря на утраченную актуальность данной темы.

[imir]

Цитата:

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

Кстати, а в обновлении для 4-ки
XPO-шка сравнительно небольшая - 2,7 мега.

Явно что-то не так в датском королевстве.

Для 9-ки тоже 2.6 это не суть. В проекте 16 таблиц, в которых перекурочена половина полей и методов - там есть такие странные вещи - новые поля на таблицах, явно не к месту, по старым сменены метки, новые методы для aif. Короче - нифуя не похоже, что ТТН накатывали на чистый RU7 - похоже, что его накатили на какой-то пре-релиз RU8, накидали в проект еще до кучи объектов да так и выгрузили со слоя вместе со всеми правками

[ice]

Цитата:

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

Для 9-ки тоже 2.6 это не суть. В проекте 16 таблиц, в которых перекурочена половина полей и методов - там есть такие странные вещи - новые поля на таблицах, явно не к месту, по старым сменены метки, новые методы для aif. Короче - нифуя не похоже, что ТТН накатывали на чистый RU7 - похоже, что его накатили на какой-то пре-релиз RU8, накидали в проект еще до кучи объектов да так и выгрузили со слоя вместе со всеми правками

поделитесь плз ссылкой для 2009, а то приведенная выше ссылка ссылается на хот фикс, который в запакованном виде ~9Mb, а его 2 xpo по 50Mb