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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 10.01.2014, 13:18   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
черновики (заказы) - могут удаляться. Поэтому данные в заказах хранить нельзя. Фактические данные нужно протаскивать в документы.
вынес обсуждение в отдельную тему
Цитата:
Сообщение от pitersky Посмотреть сообщение
Цитата:
Сообщение от mazzy Посмотреть сообщение
не забывайте, что заказы - это черновики (заказы - могут удаляться). Поэтому данные в заказах хранить нельзя. Фактические данные нужно протаскивать в документы.
уже второй раз встречаю этот тезис.
насколько я понимаю логику системы, удалять можно строки заказа/журнала. Ибо важны не строки, а проводки.
Но заголовок??? Производные документы (отборки, накладные) далеко не всегда содержат данные, которые есть в заголовке заказа. Те же кластеры, к примеру, которые протаскивать в накладные совершенно не нужно. Да и бизнес-логика в удалении именно заголовка заказа мне лично непонятна.
логика работы системы такая:
* журналы - суть черновики.
* черновик может правится пользователем в любой момент ПОКА не разнесен.
* черновик может быть удален в любой момент
* разноска журнала полностью переносит информацию из черновика в фактические таблицы (в т.ч. в таблицы журнализации)
* черновик может дать информацию об ожидаемых операциях (но не факт, что эти ожидания сбудутся), факт нужно собирать по фактически сделанным операциям.

заказ - специальный вид журнала.
* заказ также черновик
* заказ также может удаляться в любой момент
* в отличие от журнала, заказ можно разносить несколько раз.
* но между разными разносками параметры в заказе могут изменяться (!!!!!!)

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

это в теории.
=====================
на практике (особенно очень часто в локализации) журнал трактуется как 1Совский документ, в котором хранятся параметры.
К сожалению!

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

Из за того, что параметры могут быть разными - нет никакой логической причины, из-за которой нужно брать параметры операции/документа из заказа!
=====================
никогда не обращайтесь к заказу в отчетах.
протаскивайте параметры из заказа в фактический документ.
и будет вам щастье.

Последний раз редактировалось mazzy; 10.01.2014 в 13:30.
За это сообщение автора поблагодарили: Vals (1), alex55 (1), Corel (1), Axal (1).
Старый 10.01.2014, 14:27   #2  
MikeR is offline
MikeR
MCT
Аватар для MikeR
MCBMSS
Лучший по профессии 2015
Лучший по профессии 2014
 
1,628 / 627 (24) +++++++
Регистрация: 28.11.2005
Адрес: просто землянин
Цитата:
Сообщение от mazzy Посмотреть сообщение
вынес обсуждение в отдельную тему


никогда не обращайтесь к заказу в отчетах.
протаскивайте параметры из заказа в фактический документ.
и будет вам щастье.
Может я один такой и всегда строю отчеты либо по проводкам/операциям, либо по документам...
__________________
Axapta book for developer
Старый 10.01.2014, 15:06   #3  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
никогда не обращайтесь к заказу в отчетах.
протаскивайте параметры из заказа в фактический документ. и будет вам щастье.
Из-за м... лени что ли касаемо протаскивания дополнительных параметров из заказов/журналов и последующего отказа от удаления заказов/журналов со временем обычно возникают очень большие проблемы с производительностью. Логика работы системы, кроме прочего, еще подразумевает, что в любой момент времени черновиков (если угодно, work in progress, WIP) в системе не должно быть слишком много. При таком условии формы работы с черновиками работают очень шустро, позволяя пользователям фильтровать/сортировать черновики фактически по любым полям без каких-либо ощутимых тормозов. А если те же заказы не удалять после полного оприходования, то со временем форма заказов начнет открываться со скрипом, фильтрация/сортировка по неиндексированным полям (ибо кто ж запретит) будет нагружать СУБД и подвешивать клиента Аксапты, а "безобидные" executeQuery/findRecord для перепозиционирования на заказе после какой-нить операции могут приводить к тому, что клиент попытается утянуть всю таблицу шапок заказов в память со всеми вытекающими последствиями для себя, СУБД и соседей по терминальному серверу. Так что еще и из соображений производительности WIP в виде черновиков лучше держать под контролем и всё оприходованное/разнесенное удалять.
За это сообщение автора поблагодарили: mazzy (2).
Старый 11.01.2014, 14:29   #4  
Kabardian is offline
Kabardian
Талантливый разгвоздяй
Аватар для Kabardian
 
424 / 338 (12) ++++++
Регистрация: 14.12.2008
Адрес: Москва
Записей в блоге: 14
Полностью согласен с тезизом "Заказы - черновики".

А можете поеделиться опытом, на скольких проектах из общего числа удалось уговорить пользователей на удаление заказов? Не обязательно абсолютные цифры указывать, можно в % от общего числа. Проекты на Axapta 3.0 не в счет из-за ограничений recid...
Старый 11.01.2014, 19:50   #5  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Я правильно понял основную мысль:

Если потребовался отчет, который использует некий реквизит заказа, то необходимо изменить структуру данных с тем, чтобы "протащить" потребовавшийся реквизит во все разнесенные документы?

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

С точки зрения пользователя именно заказ является исходным документом. А все накладные и фактуры, пораждаемые из него - это всего-лишь некие "печатные формы". Вот Вы бы сами согласились бы хранить только печатные формы без исходников?
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 11.01.2014, 19:58   #6  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Если правильно, то, мягко выражаясь, не жирно ли будет? Как с точки зрения трудозатрат на эту модификацию
не жирно.
трудозатраты не слишком высокие, если знать фреймворк FormLetter.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
С точки зрения пользователя именно заказ является исходным документом. А все накладные и фактуры, пораждаемые из него - это всего-лишь некие "печатные формы". Вот Вы бы сами согласились бы хранить только печатные формы без исходников?
Во-первых, не надо прикрываться пользователями. Мысль об "исходном документе" засевают консультанты.

Во-вторых, еще раз:
* заказ можно разносить частично.
* Между частичными разносками параметры заказа можно менять
* о каком исходнике вы говорите для "печатной формы", которая была разнесена до изменения параметров?


В том то и дело:
заказ - черновик. Заказ - не исходный документ. Поэтому данные в заказах хранить нельзя. Фактические данные нужно протаскивать в документы. И уже документы, созданные на основании заказа, являются исходными документами.
Старый 11.01.2014, 21:06   #7  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Не люблю такую категоричность, но в целом согласен про Заказы-черновики, особенно для AX до 2009. А что делать, например, с заказами типа "Контракт"? А складские журналы с русской первичкой? А ТТН (waybill), печатная форма которого тянет данные из других документов и "черновиков"? А отсутствие нормального сторнирования накладной, когда заказа уже нет?

В AX 2012 с вводом версионности ряда документов-"черновиков" парадигма несколько сместилась, мне кажется. И, например, считать ли договор - черновиком? А Заявки на покупку?
__________________
Ivanhoe as is..
Старый 11.01.2014, 21:23   #8  
RVS is offline
RVS
Сенбернар
Аватар для RVS
Злыдни
 
696 / 130 (6) +++++
Регистрация: 27.02.2003
Адрес: Королев МО
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Я правильно понял основную мысль:

Если потребовался отчет, который использует некий реквизит заказа, то необходимо изменить структуру данных с тем, чтобы "протащить" потребовавшийся реквизит во все разнесенные документы?

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

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

==

- да , Заказ есть WNP. Work In Progress..
- да, Заказ, неразнесенный, есть черновик, и может быть удален в любое время.. Mazzy, вопрос : а кто - на реальном клиенте -будед заниматься удалением заказов? Роль? Просто интересно, не видел ниразу такого (при этом я всеми руками за то , что так надо).. да.. а Заказ - частично отгружен, например?

- с точки зрения пользователя - пользователь - отдыхает.. совсем.. либо есть кто-то (роль??) , кто должен ему объяснить, что он, пользователь, не прав.. а лев.. и даже где-то слон ))
__________________
Best Regards,
Roman

Последний раз редактировалось RVS; 11.01.2014 в 21:40.
Старый 11.01.2014, 21:24   #9  
RVS is offline
RVS
Сенбернар
Аватар для RVS
Злыдни
 
696 / 130 (6) +++++
Регистрация: 27.02.2003
Адрес: Королев МО
Цитата:
Сообщение от mazzy Посмотреть сообщение
нМысль об "исходном документе" засевают консультанты.
Mazzy, вопрос к Вам - снят..
__________________
Best Regards,
Roman
Старый 11.01.2014, 21:30   #10  
RVS is offline
RVS
Сенбернар
Аватар для RVS
Злыдни
 
696 / 130 (6) +++++
Регистрация: 27.02.2003
Адрес: Королев МО
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Если потребовался отчет, который использует некий реквизит заказа, то необходимо изменить структуру данных с тем, чтобы "протащить" потребовавшийся реквизит во все разнесенные документы?
Для того, чтобы печатать __печатные формы__ - есть __отдельные таблицы.. и Вы, и я их знаем..

__Печатные__ формы - обычно регламентированы.. законодательством (как минимум), Вашими отношенияма с клиентом (как максимум)

Nothing anymore ))

Если есть идея, что __вот ЭТО__ - должно напечататься и __после__ удаления "Заказа" - 20 минут на такую доработку.. только скажите, __ что именно __ Вас интересует..
__________________
Best Regards,
Roman

Последний раз редактировалось mazzy; 12.01.2014 в 10:06.
Старый 12.01.2014, 01:06   #11  
Kabardian is offline
Kabardian
Талантливый разгвоздяй
Аватар для Kabardian
 
424 / 338 (12) ++++++
Регистрация: 14.12.2008
Адрес: Москва
Записей в блоге: 14
Цитата:
Сообщение от RVS Посмотреть сообщение
кто - на реальном клиенте -будед заниматься удалением заказов? Роль? Просто интересно, не видел ниразу такого (при этом я всеми руками за то , что так надо)..
Роль - системный администратор. Во многих модулях системы есть периодические операции по очистке данных.
Старый 12.01.2014, 10:27   #12  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А что делать, например, с заказами типа "Контракт"?
заказ типа "контракт" - это такой же черновик. только исполняется этот черновик другими заказами, которые в свою очередь исполняются фактическими документами. (пока не поглотит все вязкое трение (С) )

гораздо интереснее, как трактовать заказы с типом подписка.

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А складские журналы с русской первичкой? А ТТН (waybill), печатная форма которого тянет данные из других документов и "черновиков"?
ой, вот про локализацию не надо.
сколько раз локализация была антипаттерном.
и в этом случае тоже является.

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А отсутствие нормального сторнирования накладной, когда заказа уже нет?
э-э-э? что имеется в виду?
копирование с минусом делается и на основании накладной.
конкретная реализация алгоритма? так см. рассуждения о локализации?
или еще чего?

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
В AX 2012 с вводом версионности ряда документов-"черновиков" парадигма несколько сместилась, мне кажется.
хм... тут возможны разночтения. что именно имеется под "версионность ряда документов"?

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
И, например, считать ли договор - черновиком? А Заявки на покупку?
договор - русский? который rcontract? ой, блин, это просто справочник "как в 1С".

заявка на покупку - типичный журнал/черновик, который исполняется фактическими документами.

Цитата:
Сообщение от RVS Посмотреть сообщение
Mazzy, вопрос : а кто - на реальном клиенте -будед заниматься удалением заказов? Роль?
Цитата:
Сообщение от Kabardian Посмотреть сообщение
Во многих модулях системы есть периодические операции по очистке данных.
RVS - прекрасный вопрос про роль! В корень.
Как уже сказал Kabardian - есть процедура очистки, которую можно засунуть в пакетное задание и выполнять периодически на автомате. А также можно выделить ответственного, который будет запускать.


Но самое интересное и правильное - в параметрах клиентов и поставщиков есть галочки "Автоудаление заказов" и "автосокращение заказов". (все еще под рукой нет аксапты, чтобы сказать точное название)

Можно и нужно взводить эти галочки. тогда Аксапта сама при разноске будет удалять полностью разнесенные строчки и сокращать на разнесенное количество. В заказах останется только то, что осталось выполнить.
Старый 12.01.2014, 11:48   #13  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от mazzy Посмотреть сообщение
заказ типа "контракт" - это такой же черновик. только исполняется этот черновик другими заказами, которые в свою очередь исполняются фактическими документами. (пока не поглотит все вязкое трение (С) )

гораздо интереснее, как трактовать заказы с типом подписка.
Контракт раньше был неким аналогом Спецификации к договору - а это реальный бизнес-документ. Если его удалять, то в системе не останется возможности посмотреть план/факт.

Аналогично с заказами. Если мы хотим строить отчет об уровне сервиса - план/факт выполнения заявок клиентов или наших заявок у поставщика - нам нужно сравнить сколько заказали и сколько получили. Да, можно разносить по каждому заказу документ "Заказ" и сравнивать потом с ним. Но это лишнее движение при каждом изменении заказа и зачастую его роль и выполняет сам Заказ.

Цитата:
Сообщение от mazzy Посмотреть сообщение
ой, вот про локализацию не надо.
сколько раз локализация была антипаттерном.
и в этом случае тоже является.
С одной стороны соглашусь. С другой - опять же для пользователя не важно как оно там внутри - он видит пример и хочет "также". И согласитесь, что в последних версиях системы все больше анти-патернов по сравнению с 3.0/4.0. Добавляют новые функции не поддерживая старые подходы. И тому же пользователю сложнее стало объяснять, что "тут так не делают" - они с гордостью находят очередной косячный стандартный кусок и говорят - "вот, вы систему не знаете - можно же! хочу также".

Цитата:
Сообщение от mazzy Посмотреть сообщение
э-э-э? что имеется в виду?
копирование с минусом делается и на основании накладной.
конкретная реализация алгоритма? так см. рассуждения о локализации?
или еще чего?
Зачастую намного проще сделать сторно в том же заказе через немедленное получение. Но в целом, согласен, сейчас сторно более-менее допилили.

Цитата:
Сообщение от mazzy Посмотреть сообщение
хм... тут возможны разночтения. что именно имеется под "версионность ряда документов"?
Например, Заказ на покупку - теперь есть возможность базово отслеживать его изменения, сохранять версии, утверждать изменения и т.п. Т.е. появился целый процесс изменений "черновика" - это скорее уход от понятия "черновика" в сторону полноценного бизнес-документа.

Цитата:
Сообщение от mazzy Посмотреть сообщение
договор - русский? который rcontract? ой, блин, это просто справочник "как в 1С".
Нет, я тут уже только про 2012 говорил. Новые Agreement. Опять же с версионностью, с фиксированием цен, количеств и т.п. С одной стороны - просто черновик для создания черновика С другой - конкретная бизнес-сущность - договор с контрагентом и его условия. Они важны и сами по себе, даже если заказов нет.

Цитата:
Сообщение от mazzy Посмотреть сообщение
заявка на покупку - типичный журнал/черновик, который исполняется фактическими документами.
Тут не соглашусь. Обычно нужная история - кто и зачем что-то заказал. Если эту историю чистить, то половина задачи будет не решена. Централизация закупок обычно и требуется для наведения порядка и контроля - кто, что и зачем.
__________________
Ivanhoe as is..

Последний раз редактировалось Ivanhoe; 12.01.2014 в 11:52.
За это сообщение автора поблагодарили: EVGL (5).
Старый 12.01.2014, 14:51   #14  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Контракт раньше был неким аналогом Спецификации к договору - а это реальный бизнес-документ. Если его удалять, то в системе не останется возможности посмотреть план/факт.

Аналогично с заказами. Если мы хотим строить отчет об уровне сервиса - план/факт выполнения заявок клиентов или наших заявок у поставщика - нам нужно сравнить сколько заказали и сколько получили. Да, можно разносить по каждому заказу документ "Заказ" и сравнивать потом с ним. Но это лишнее движение при каждом изменении заказа и зачастую его роль и выполняет сам Заказ.

...
Видно, когда пишет практик. Соглашусь с каждым пунктом.
Старый 12.01.2014, 15:56   #15  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Контракт раньше был неким аналогом Спецификации к договору - а это реальный бизнес-документ. Если его удалять, то в системе не останется возможности посмотреть план/факт.
Эта логика подходит не только к контракту, но и к заказу.

Эта логика опровергается точно теми же утверждениями, что и по заказу:
1. параметры заказа с типом контракт могут изменяться между созданиями заказов по контракту. Какой план/факт вы собираетесь смотреть для заказов, созданных до изменения параметров в контракте?
2. Посмотрите как работают галочки автосокращение и автоудаление для контрактов



Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Аналогично с заказами. Если мы хотим строить отчет об уровне сервиса - план/факт выполнения заявок клиентов или наших заявок у поставщика - нам нужно сравнить сколько заказали и сколько получили. Да, можно разносить по каждому заказу документ "Заказ" и сравнивать потом с ним. Но это лишнее движение при каждом изменении заказа и зачастую его роль и выполняет сам Заказ.
Лишнее?
Еще раз: между разносками параметры в заказе можно изменять! С чем именно вы собираетесь сравнивать, если не будет "лишних движений"?



Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
С одной стороны соглашусь. С другой - опять же для пользователя не важно как оно там внутри - он видит пример и хочет "также". И согласитесь, что в последних версиях системы все больше анти-патернов по сравнению с 3.0/4.0. Добавляют новые функции не поддерживая старые подходы. И тому же пользователю сложнее стало объяснять, что "тут так не делают" - они с гордостью находят очередной косячный стандартный кусок и говорят - "вот, вы систему не знаете - можно же! хочу также".
абсолютно согласен.
Но это не повод не знать как именно было задумано изначально.


Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Например, Заказ на покупку - теперь есть возможность базово отслеживать его изменения, сохранять версии, утверждать изменения и т.п. Т.е. появился целый процесс изменений "черновика" - это скорее уход от понятия "черновика" в сторону полноценного бизнес-документа.
а... об этом... от введения такой функциональности заказ на закупку не перестает быть черновиком.
Еще раз: параметры заказа можно изменять между разносками!

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Нет, я тут уже только про 2012 говорил. Новые Agreement. Опять же с версионностью, с фиксированием цен, количеств и т.п. С одной стороны - просто черновик для создания черновика С другой - конкретная бизнес-сущность - договор с контрагентом и его условия. Они важны и сами по себе, даже если заказов нет.
да, с этим согласен.
но от этого заказ не перестает быть черновиком

Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Тут не соглашусь. Обычно нужная история - кто и зачем что-то заказал. Если эту историю чистить, то половина задачи будет не решена. Централизация закупок обычно и требуется для наведения порядка и контроля - кто, что и зачем.
историю в черновиках можно и не чистить.
но от этого черновики не перестают быть черновиками

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

я же сказал ровно то, что сказал: черновики (заказы) - могут удаляться. Поэтому данные в заказах хранить нельзя. Фактические данные нужно протаскивать в документы.
За это сообщение автора поблагодарили: RVS (1).
Старый 12.01.2014, 16:05   #16  
RVS is offline
RVS
Сенбернар
Аватар для RVS
Злыдни
 
696 / 130 (6) +++++
Регистрация: 27.02.2003
Адрес: Королев МО
Цитата:
Сообщение от Kabardian Посмотреть сообщение
Роль - системный администратор. Во многих модулях системы есть периодические операции по очистке данных.
Нет... админ - у него другая роль...

==

Мимо, работаем ))
__________________
Best Regards,
Roman
Старый 12.01.2014, 16:30   #17  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
С точки зрения пользователя именно заказ является исходным документом. А все накладные и фактуры, пораждаемые из него - это всего-лишь некие "печатные формы"
Нет ну всему же должен быть предел, в том числе и клиентоориентированности Пользователь хочет "как проще", проблемы аудита, целостности и непротиворечивости данных его не волнуют. Он сам поправит Ваш "исходный документ" (заказ) "как должно быть" а потом Вас же будет гонять "система №;%" и "печатные формы не сходятся". А Вы еще будете молиться чтобы на Ваши "исходные документы" в течение года-двух до окончания всевозможных аудитов никто не дышал. Так что - нет, не жирно, а "протаскивать", только так
__________________
-ТСЯ или -ТЬСЯ ?
Старый 12.01.2014, 16:37   #18  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
Во-первых, не надо прикрываться пользователями. Мысль об "исходном документе" засевают консультанты.
Я бы сказал наоборот. Мысль о "черновике" засевают программисты! Просто потому, что без постоянных отсылок к заказу проще программировать.

Цитата:
Сообщение от mazzy Посмотреть сообщение
Во-вторых, еще раз:
* заказ можно разносить частично.
Можно. Но я ни разу не видел, чтобы так делали. В смысле, частичную разноску. Обычно заказ разносят целиком. Именно по той причине, что воспринимают заказ вовсе не как "черновик", а как "исходник". Т.е. цельный и завершенный документ.

Как следствие, заказы не просто не разносят частично, но еще и дополнительный контроль на это дело навешивают, чтобы случайно частично не разнести!

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

Ну, возьмем простой пример. Купили/продали некий товар. Чтобы создать накладную надо сначала сформировать заказ. Вполне логично делать отдельный заказ на каждую "бумажную накладную". Что в "бумажке", то и в заказе.

При таком подходе, естественно, ни о какой частичной разноске не может быть и речи. И частичная разноска воспринимается пользователем как нечто "не естественное". Не совпадают введенные и "бумажные" данные.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 12.01.2014, 16:39   #19  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от Vadik Посмотреть сообщение
Нет ну всему же должен быть предел, в том числе и клиентоориентированности Пользователь хочет "как проще", проблемы аудита, целостности и непротиворечивости данных его не волнуют. Он сам поправит Ваш "исходный документ" (заказ) "как должно быть" а потом Вас же будет гонять "система №;%" и "печатные формы не сходятся". А Вы еще будете молиться чтобы на Ваши "исходные документы" в течение года-двух до окончания всевозможных аудитов никто не дышал. Так что - нет, не жирно, а "протаскивать", только так
Не поправит. После разноски заказ блокируется. Запрет на редактирование. Кстати, эта возможность предусмотрена стандартным функционалом. Правда, по желанию (можно блокировать, а можно и не блокировать)
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 12.01.2014, 16:58   #20  
RVS is offline
RVS
Сенбернар
Аватар для RVS
Злыдни
 
696 / 130 (6) +++++
Регистрация: 27.02.2003
Адрес: Королев МО
Блин.. вот читаю, то, что написали - умные люди.. и никак не пойму.. а зачем...

я - тупой (с)

===

О жизни, как она есть :

- Заказ есть Заказ (с большой буквы ЗЗ), пока :

- он, Заказ - не отменем клиентом (клиентв - всегда прав, да)
- пока обязательства (О!! А вЗаказе - __нет__ обязательств.. уй, ёё.. это уже вовсе другие вещи..) перед Клиентом - не выполнены.. но, кстати - это уже отдельные товарно-денежные отношения..

==

Ну, собственно.. мне лично - все понятно. Зайдите на любой сайт в инете, который что-то продает..

БП - понятен.. есть.. pecularuties.. но от этого - ни клиент, у которого БП, ни сам БП - не меняются...

==

"Все уже придумано до нас".. (с) А&BСтругацкие...
__________________
Best Regards,
Roman
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Сомнение возникло в рекомендации "нужно использовать collation, который позволяет хранить в юникоде (например, Cyrilic_General_CI_AS)" VitaliyK DAX: Администрирование 10 25.09.2007 13:50
заказы: данные о компании в накладной doxlokot DAX: Функционал 5 07.02.2004 03:24
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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