26.05.2009, 01:13 | #1 |
Участник
|
Предислование: Долго думал куда в Тему поместить, но тешил сюда - всё равно ничего от этого не поменяется...
Недавно делал по заказу перенос Учёта внутренних перемещений (Журнал реклассификации отправили в топку Заказчики). Всё вроде ясно и понятно. Но иногда диву даёшься зачем так раздувать кол-во CodeUnit"ов!! 12460 Item Doc.-Post Receipt потчи похож на 12461 Item Doc.-Post Shipment Неужели нельзя было слить воедино и оставить 1 "дырку в нумерации" для чего-то нужного??? У меня объединение заняло всего 1 ЧАС!!! + ToolKit наверное не пользовались, так как ни единой записи по полю "Docunet Type" в "смежных кодах" нет - см. например форму 38, CodeUnit 5836 Cost Calculation Management (про такие важные CodeUnit 6529 Item Tracking Navigate Mgt., 17206 Create Tax Register Item Entry, 12306 Create Tax Calc. Item Entries со связанными таблицами (нумерация поля вместо №79 гуляет как хочет) я просто промолчу...). CodeUnit 12452 Item Doc. Line-Reserve в триггере VerifyChange или DeleteLine можно немного сократить. Стоить хотя бы взглянуть на код IF HasErrorOutbnd THEN BEGIN и IF HasErrorInbnd THEN BEGIN. Различие только в одной проверке: (NewItemDocLine."Location Code" <> OldItemDocLine."Location Code"). А вот примение функции CallItemTracking2 так и не нашёл. Вобщем было бы не так жалко и смешно, если бы не грусно.. Её раз убеждаюсь, что код не только на переменные, но даже на "простое дублирование" даже не проверяют... |
|
09.06.2009, 00:51 | #2 |
Участник
|
Цитата:
Сообщение от RedFox
Стоить хотя бы взглянуть на код IF HasErrorOutbnd THEN BEGIN и IF HasErrorInbnd THEN BEGIN. Различие только в одной проверке: (NewItemDocLine."Location Code" <> OldItemDocLine."Location Code").
А вот примение функции CallItemTracking2 так и не нашёл. Вобщем было бы не так жалко и смешно, если бы не грусно.. Её раз убеждаюсь, что код не только на переменные, но даже на "простое дублирование" даже не проверяют... "Различие только в одной проверке" - да, не спорю. Но такое в наве Вы найдете повсеместно. А функции, которые отличаются типом одного параметра! Тоже не редкость! Здесь нет возможности создавать перегруженные методы и использовать прочие обыденные радости жизни, как в любом более-менее нормальном языке... В наве иногда проще и полезнее продублировать код, чем городить, простите, хрень, из кучи проверок. Увы... |
|
10.06.2009, 19:36 | #3 |
Участник
|
Цитата:
Цитата:
А функции, которые отличаются типом одного параметра! Тоже не редкость! Здесь нет возможности создавать перегруженные методы и использовать прочие обыденные радости жизни, как в любом более-менее нормальном языке...
Цитата:
В наве иногда проще и полезнее продублировать код, чем городить, простите, хрень, из кучи проверок. Увы...
Или легче написать дублирующий код, чем попытаться разобраться в существующем? При этом этот когд ПРОСТО НЕ НУЖЕН (функция CallItemTracking2)! Я мог даже сказать какой кодеюнит был "прообразом" и где эта функция работает (когда доделывал код) |
|
03.07.2009, 12:47 | #4 |
Участник
|
Цитата:
Сообщение от RedFox
Тоесть в итоге Вы частично согласились, что лучше попытаться написать немного оптимальнее код, кем плодить функции?
Или легче написать дублирующий код, чем попытаться разобраться в существующем? При этом этот когд ПРОСТО НЕ НУЖЕН (функция CallItemTracking2)! Я мог даже сказать какой кодеюнит был "прообразом" и где эта функция работает (когда доделывал код) Вопрос - в чем проблема "подкорректировать код триггера PrintRecords для Item Shipment Header? |
|