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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 09.04.2013, 07:15   #1  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Правильно ли сделан функционал и организован процесс?
Есть некоторый функционал рекламных акций... собс-но просто какая то болванка, таблицы шапок, строк, мест проведения и периодов, которые не несут какой то особой смысловой нагрузки... данные таблицы просто попадает в кассовую программу которая уже сама по себе расчитывает какие то скидки... никаких проверок на пересечение рекламных акции - нет, хотя по процессу их и не должно быть в рамках одного типа скидочной карты, причем работать из этих двух, трех и тд пересекающихся акции будет только та у которой некоторой цифровое поле генерируемое аксаптой и нередактируемое будет меньше. У акции есть некоторый период её действия, ну поскольку пользовтели не особо задумываются и ленятся то включают и выключают редактируют(меняют например номенклатуру), включить могут как в прошлом так и в настоящем да и в будущем. Все бы ничего но от меня требуют получать какие то данные для выгрузок, для OLAP-кубов и тп... ну например сколько по каким то акциям было продано товара, какая цена у товара была по акции, оповещать пользователей о начале и конце рекламных акций(чтобы успели поменять ценники в магазинах)(продажи и цены попадают в аксапту из кассовых аппаратов)
Решил как то ограничить пользователей для того чтобы хотя бы как то и что то получать точно, а не "сферического коня в вакууме", т.е. отменять проведение/включение/разноску действующих рекламных акций только по письменному запросу, разработать какой то алгоритм действий сверки правильности рекламной акции до ее начала, а не после, запретить проведение/разноску/включение рекламных акции в прошлом(всем кроме администратора ибо синхронизация с кассовой программой идет вроде бы с каким то неочень большим промежутком времени), запретить включение/разноску/проведение пересекающихся акций(избавиться от непонятной и какой то "машинной" логики по цифровым полям), сделать как бы проводки по рекламным акциям(ну т.е. хранящие историю действия этих рекламных акций)... Не знаю насколько предложение рационально, но мне сказали что тут главное это то чтобы пользователи могли сами все исправлять... Акции могут быть большими, т.е. смсками тут тоже оповещение ну наверное никак не сделаешь
Внимание вопрос: правильно ли организован процесс на предприятии?
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!

Последний раз редактировалось Murlin; 09.04.2013 в 07:18.
Старый 09.04.2013, 08:25   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Murlin Посмотреть сообщение
пользовтели не особо ... включают и выключают редактируют
...
Решил как то ограничить пользователей... запретить
...
Не знаю насколько предложение рационально, но мне сказали что тут главное это то чтобы пользователи могли сами все исправлять...
Не очень рационально.
С людьми не стоит бороться. Такова их природа.

Лучше пусть делают что угодно. Но вести тщательные логи - похожие на проводки.
И отчеты строить по таким логам/проводкам. Похоже на финансовый учет в Аксапте.

Получится чуть сложнее, но железобетонно с точки зрения отчетов.
Старый 09.04.2013, 09:08   #3  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от mazzy Посмотреть сообщение
Не очень рационально.
С людьми не стоит бороться. Такова их природа.

Лучше пусть делают что угодно. Но вести тщательные логи - похожие на проводки.
И отчеты строить по таким логам/проводкам. Похоже на финансовый учет в Аксапте.

Получится чуть сложнее, но железобетонно с точки зрения отчетов.
а какой смысл тогда в проводках если они будут содержать "сферического коня в вакууме"?
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!
Старый 09.04.2013, 09:55   #4  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от Murlin Посмотреть сообщение
а какой смысл тогда в проводках если они будут содержать "сферического коня в вакууме"?
Проводки помогут разобраться как этот конь сформировался. Если пользователям всё-равно, то возможно руководству будет не всё равно.
Старый 09.04.2013, 10:03   #5  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Для начала Вам надо уточнить, должна ли в отчетах отображаться история или же все отчеты строятся по состоянию на "сейчас". Поясню

Допустим, у Вас действовала на 01 число некая акция. По этой акции был продан товар. Затем пользователь подумал и изменил период действия акции не с 01, а, скажем, с 10 числа.

Вопрос: Как в отчете надо отобразить товар, проданный 01 числа? Как проданный по акции, действовавшей на это число или же безо всякий акций, поскольку сейчас эта акция начинается с 10 числа.

Так вот, если Вам надо отображать историю, то придется делать отдельное хранилище (или логи - не суть), где и хранить эту историю. Соответственно, все отчеты будут строится по этим логам. Если всегда по состоянию на "сейчас", то можно оставить "как есть".

PS: поскольку после закрытия склада товародвижение в закрытом периоде невозможно, то можно автоматом ограничить изменение задним числом по дате последнего закрытия склада.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 09.04.2013, 10:05   #6  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Murlin Посмотреть сообщение
а какой смысл тогда в проводках если они будут содержать "сферического коня в вакууме"?
сферического коня? в сферическом коне никакого смысла.
я думал, что вы будете записывать историю, которую творят пользователи.
Старый 09.04.2013, 10:10   #7  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Для начала Вам надо уточнить, должна ли в отчетах отображаться история или же все отчеты строятся по состоянию на "сейчас". Поясню

Допустим, у Вас действовала на 01 число некая акция. По этой акции был продан товар. Затем пользователь подумал и изменил период действия акции не с 01, а, скажем, с 10 числа.
"сферический конь в вакууме" :-) с 01 на 10. с на сейчас все и так понятно... проблема только в том что и на сейчас работает неочень понятно(про цифровое поле)
я когда сказал менеджеру что если даже акция и включена то не факт что она действует ее немного переклинило... да и соб-на я вообще не понимаю как можно акции проверять когда они уже запущены. Будущее не страшно я уже придумал что историю буду перетирать полностью которая в будущем. Но вот незадача акции большие по многим магазинам с периодичностью(только во вторник например с 2х до 3х)... будет а) тормозить б) акции которые на прошлые периоды будут просто засорять историю что за акция которая действовала 30 секунд?
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!
Старый 09.04.2013, 10:13   #8  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от mazzy Посмотреть сообщение
сферического коня? в сферическом коне никакого смысла.
я думал, что вы будете записывать историю, которую творят пользователи.
мне не просто история нужна а история для получения каких то данных, желательно фактических зачем мне чисто теоретические??? что с помощью теоретических данных они хотят увидеть?
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!
Старый 09.04.2013, 10:18   #9  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Что-то какой-то "поток сознания". При чем здесь какие-то числовые поля?

Есть заказ на продажу. На момент проведения этого заказа действует акция. Действующая акция влияет на цену/сумму продажи? Если влияет, то Вы просто обязаны создать дополнительные поля, как минимум, в строках заказа (идеально - в логах), где и зафиксировать информацию, на основании которой такая цена получилась. Иначе как Вы потом будете объяснять руководству, почему товар продали за 5 руб, если его цена 10? Это даже не отчеты, это банальный "разбор полетов"
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 09.04.2013, 10:27   #10  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Что-то какой-то "поток сознания". При чем здесь какие-то числовые поля?

Есть заказ на продажу. На момент проведения этого заказа действует акция. Действующая акция влияет на цену/сумму продажи? Если влияет, то Вы просто обязаны создать дополнительные поля, как минимум, в строках заказа (идеально - в логах), где и зафиксировать информацию, на основании которой такая цена получилась. Иначе как Вы потом будете объяснять руководству, почему товар продали за 5 руб, если его цена 10? Это даже не отчеты, это банальный "разбор полетов"
Есть пересекающиеся акции по одному и тому же товару одному и тому же магазину типу дисконтной карты в рамках сегодняшнего дня, так вот вычисление реальной активной акции делается по некоему цифровому полю там где это поле меньше та и является фактически активной. Такая вот еще проблема... т.е. по нормальному одну акцию надо откатить(обрезать до текущего момента), вторую провести(и только с текущего момента не важно чего там написано) уведомить пользователей...
а если вот эти откаты проведение будут по 100 раз в день делать? что будет с историей, пользователями?
Как фиксировать то? каким образом... они могут спокойно акцию провести завтрашним днем когда акция не действовала, не могу же я пойти и забрать товар у покупателя... просто я сделал вывод что для акции как бы закрытым периодом(в котором нельзя проводить задней датой) текущий момент времени-0.000000000000000001 милисекунды. а потом руководство спросит а вот почему? и что ответить? по истории запись есть а товар чего это продали по такой цене
я вот и спрашиваю правильно ли вообще устроен процесс? или лучше логировать и разбирать полеты или лучше сразу в чем то ограничить?
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!

Последний раз редактировалось Murlin; 09.04.2013 в 10:34.
Старый 09.04.2013, 11:10   #11  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Как то делали похожий ОЛАП. В итоге пошли на упрощение - в одном кубе была несвязанная информация о продажах и об акциях, действовавших по товару / периоду. Не раскрывая аналитику "Акция" по товару можно было видеть Выручку и количество акций на момент времени, при желании - раскрываем аналитику "Акция", по пустому значению "Акция" видим факт продаж, отдельными строками - коды акций, но пустые продажи.
__________________
Ivanhoe as is..
Старый 09.04.2013, 11:11   #12  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Действия пользователя в системе должны быть осмысленны. Когда пользователь для получения конечного результата сам вынужден определять и выполнять набор несвязных действий - это повышает требование к квалификации такого пользователя. Возможно нужно сгруппировать настройки и операции в какие-нибудь мастер-формы, визарды; реализовать вспомогательные операции при помощи журналов, разнося которые пользователь отражает изменения одновременно в нескольких таблицах.
Цитата:
Сообщение от Murlin Посмотреть сообщение
мне сказали что тут главное это то чтобы пользователи могли сами все исправлять...
"ВСЕ - нехорошее слово. Как только появляется слово ВСЕ - жди логической ошибки." (c) mazzy


Подход при котором управление системой полностью отдан на откуп пользователю часто возникает там, где нет ясной формализации процессов.
Цитата:
Сообщение от Murlin Посмотреть сообщение
правильно ли организован процесс на предприятии?
Сдаётся мне, что он не организован
За это сообщение автора поблагодарили: mazzy (2), Murlin (1).
Старый 09.04.2013, 11:15   #13  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Слишком много "буков" Разбивай задачу на этапы.

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

Аксимома 2: Если заказа проведен по бухгалтерии, то изменить его невозможно! Нужно сторнирование и проведение заново, но уже как нового заказа (новые складские проводки, новые логи)

Т.е. выбирать/сохранять какие-либо реквизиты надо один раз в момент обработки заказа. Либо обработки счета-фактуры, либо накладной. Смотря по тому, в какой момент требуется окончательная цена в зависимости от бизнес-процессов. Ну, и необходимо блокировать возможность изменения реквизитов заказа, влияющих на цену после обработки

Лично у нас вообще сделана отдельная кнопка "Пересчет цен по прайсу", которая выполняется после резервирования, но до обработки заказа. Причем без пересчета цен обработка невозможна (пункты меню блокируются). Специальная галка в шапке заказа добавлена.

Соответсвенно, фиксируем только и исключительно то, что действовало на момент проведения заказа. И не важно, что там было "до" или стало "после". Еще менее важен интервал изменений. Хоть сутки, хоть год, хоть миллисекунды. Что "попало" в момент проведения, то и использовали.

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

Ну, а что именно надо зафиксировать - это уже другой вопрос.

Другими словами, не важно как и кто будет менять справочники акций, но если они влияют на цену продажи, то они должны быть зафиксированы на момент проведения заказа либо в самом заказе, либо в отдельной таблице логов, привязанных к конкретному заказу по аналогии со складскими проводками
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
За это сообщение автора поблагодарили: mazzy (2).
Старый 09.04.2013, 11:24   #14  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Другими словами, не важно как и кто будет менять справочники акций, но если они влияют на цену продажи, то они должны быть зафиксированы на момент проведения заказа либо в самом заказе, либо в отдельной таблице логов, привязанных к конкретному заказу по аналогии со складскими проводками
ну это понятно конечно, что надо перепроводить заказы в том числе в таком случае но я боюсь что на такое не пойдут воообще.
я вот и думаю чеже делать то... город маленький...
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!
Старый 09.04.2013, 11:33   #15  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от Murlin Посмотреть сообщение
ну это понятно конечно, что надо перепроводить заказы в том числе в таком случае но я боюсь что на такое не пойдут воообще.
я вот и думаю чеже делать то... город маленький...
Так в 1С, насколько я в курсе, тоже перепроводят заказы в таких случаях. Правда, там это организовано без сторнирования (кажется, пункт меню "Распровести"), но все-равно делают то же самое.

Спроси у бухов, как они будут относится к ситуации, когда суммы бух.проводок будут меняться произвольным образом и без их ведома. Как они вообще отчеты для налоговой сдавать будут? "Столкни лбами" менеджера и глав.буха. Пусть они сначала разберутся между собой.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 09.04.2013, 11:51   #16  
Starling is offline
Starling
Участник
Дети Юза
 
530 / 76 (4) ++++
Регистрация: 20.10.2005
Адрес: Kiev
To Владимир Максимов
Вообще конечно со всем согласен, но вот этот пункт
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Аксиома 1: данные, влияющие на конечную цену продажи, должны так или иначе быть сохранены, для возможного "разбора полетов". Иначе программист всегда будет крайним: "программа плохая", "я ничего не менял", "она сама посчитала"
В стандарте реализован не самым лучшим образом. Причина в том, что к одной строке заказа на продажу может быть применено несколько скидок. Как пример несколько скидок по строке - одна настроена на уровне клиента, другая на уровне группы клиентов. Эти скидки суммируются и разобрать потом, как они получились уже очень проблематично. А если коммерческие соглашения менялись, то почти невозможно.
Я не нашел ни какого универсального решения этой проблемы. На конкретном проекте пришлось вводить ряд ограничений:
1. Использовать многострочные скидки, хотя по свой природе это были скидки по строке, чтобы отдельно выделять их.
2. Запретить административно использовать более чем одну скиду по строке к одному заказу на продажу.
3. Ряд скидок вынести на накладные расходы.
В целом хранить историю цены получилось, но решение далеко не универсальное.
Стояла ли перед вами такая задача, если да, то как вы ее решали.
Старый 09.04.2013, 12:06   #17  
mnt_dx is offline
mnt_dx
Участник
Axapta Retail User
Лучший по профессии 2014
 
1,744 / 188 (10) ++++++
Регистрация: 17.02.2011
Адрес: К Северу через Северо-Запад
Murlin, а почему эти акции пересекаются?
Мое мнение:
1) надо выяснить и сформулировать случаи, когда акции могут пересекаться
2) сделать в системе предупреждения менеджерам, создающим акции, что их новая акция пересекается с другой активной акцией.
3) при сохранении пересекающихся акций отправлять уведомление руководителю, например, директору магазина/директору по маркетингу.
Старый 09.04.2013, 12:11   #18  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от Starling Посмотреть сообщение
Стояла ли перед вами такая задача, если да, то как вы ее решали.
Ну, у нас несколько попроще. Изменение задним числом, конечно, возможно, но это целая история с вовлечением в процесс кучи народа. Так что, нет особой необходимости хранить историю изменений именно в заказе. Сами справочники не меняются задним числом. Поэтому вполне досточно хранить лог изменения таблицы скидок через стандартный SysDataBaseLog

В общем случае, насколько я понимаю, нет и не может быть какого-либо универсального решения, поскольку, в первую очередь, все упирается в некие организационные (административные) меры, завязанные на конкретные бизнес-процессы организации.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 09.04.2013, 12:25   #19  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от mnt_dx Посмотреть сообщение
Murlin, а почему эти акции пересекаются?
Мое мнение:
1) надо выяснить и сформулировать случаи, когда акции могут пересекаться
2) сделать в системе предупреждения менеджерам, создающим акции, что их новая акция пересекается с другой активной акцией.
3) при сохранении пересекающихся акций отправлять уведомление руководителю, например, директору магазина/директору по маркетингу.
Оно как бы есть но ругается на товар и работает при сохранении !!!! СТРОКИ!!!! скидки с номенклатурой, простой warning. причем такие же длинные и непростые методы про которые я написал в другой теме(особенно радостно это все высчитывать в олапах и дисплей методах)

Пересекающиеся акции есть потому что они есть... реально есть в системе по данным...
Когда пересекаются выяснял сам у спеца по кассовой программе, ну скидочная система достаточно простая, ничего ни с чем пересекаться не должно... насколько я все это понял. или всмысле как пересекаются??? по коду номенклатуры, складу, типу дк и времени ест-но...
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!

Последний раз редактировалось Murlin; 09.04.2013 в 12:36.
Старый 09.04.2013, 12:30   #20  
Starling is offline
Starling
Участник
Дети Юза
 
530 / 76 (4) ++++
Регистрация: 20.10.2005
Адрес: Kiev
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
В общем случае, насколько я понимаю, нет и не может быть какого-либо универсального решения, поскольку, в первую очередь, все упирается в некие организационные (административные) меры, завязанные на конкретные бизнес-процессы организации.
Вообще наверно задачу нужно разбить на две части:
1. Хранить историю изменения коммерческих соглашений, для этих целей подходит журнал коммерческих соглашений. И на его основании можно было бы формировать отчеты. В 2012 все коммерческие соглашения можно менять только через эти журналы. И автору я бы советовал посмотреть в эту сторону.

2. Хранить историю ценообразования для конкретной продажи. У меня были сложности именно с этим.

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

Но так как удалось "запихнуть" историю почти в стандарт с учетом описанных выше ограничений, то от этой идеи отказались.
Как по мне такое решение было более универсальным.
Теги
как правильно

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Иморт из Excel 2010. Как правильно закрыть Excel? jkspb DAX: Программирование 4 13.10.2013 00:55
Как правильно создавать новые и использовать существующие SecurityKey Владимир Максимов DAX: Программирование 26 20.04.2011 20:45
Как правильно хранить статичный набор начальных данных в классах? mazzy DAX: Программирование 58 14.04.2011 12:10
Открытая сумма по счету-фактуре - как правильно вычислить? IKA DAX: Программирование 7 21.03.2011 19:46
Как правильно настроить возврат материалов из производства? Tony Green DAX: Функционал 14 22.10.2004 11:33
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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