черновики (заказы) - могут удаляться. Поэтому данные в заказах хранить нельзя. Фактические данные нужно протаскивать в документы.

[mazzy]

вынес обсуждение в отдельную тему

Zitat:

Zitat von pitersky

Zitat:

Zitat von mazzy

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

уже второй раз встречаю этот тезис.
насколько я понимаю логику системы, удалять можно строки заказа/журнала. Ибо важны не строки, а проводки.
Но заголовок??? Производные документы (отборки, накладные) далеко не всегда содержат данные, которые есть в заголовке заказа. Те же кластеры, к примеру, которые протаскивать в накладные совершенно не нужно. Да и бизнес-логика в удалении именно заголовка заказа мне лично непонятна.

логика работы системы такая:
* журналы - суть черновики.
* черновик может правится пользователем в любой момент ПОКА не разнесен.
* черновик может быть удален в любой момент
* разноска журнала полностью переносит информацию из черновика в фактические таблицы (в т.ч. в таблицы журнализации)
* черновик может дать информацию об ожидаемых операциях (но не факт, что эти ожидания сбудутся), факт нужно собирать по фактически сделанным операциям.

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

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

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

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

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

[MikeR]

Zitat:

Zitat von mazzy

вынес обсуждение в отдельную тему


никогда не обращайтесь к заказу в отчетах.
протаскивайте параметры из заказа в фактический документ.
и будет вам щастье.

Может я один такой и всегда строю отчеты либо по проводкам/операциям, либо по документам...

[gl00mie]

Zitat:

Zitat von mazzy

никогда не обращайтесь к заказу в отчетах.
протаскивайте параметры из заказа в фактический документ. и будет вам щастье.

Из-за м... лени что ли касаемо протаскивания дополнительных параметров из заказов/журналов и последующего отказа от удаления заказов/журналов со временем обычно возникают очень большие проблемы с производительностью. Логика работы системы, кроме прочего, еще подразумевает, что в любой момент времени черновиков (если угодно, work in progress, WIP) в системе не должно быть слишком много. При таком условии формы работы с черновиками работают очень шустро, позволяя пользователям фильтровать/сортировать черновики фактически по любым полям без каких-либо ощутимых тормозов. А если те же заказы не удалять после полного оприходования, то со временем форма заказов начнет открываться со скрипом, фильтрация/сортировка по неиндексированным полям (ибо кто ж запретит) будет нагружать СУБД и подвешивать клиента Аксапты, а "безобидные" executeQuery/findRecord для перепозиционирования на заказе после какой-нить операции могут приводить к тому, что клиент попытается утянуть всю таблицу шапок заказов в память со всеми вытекающими последствиями для себя, СУБД и соседей по терминальному серверу. Так что еще и из соображений производительности WIP в виде черновиков лучше держать под контролем и всё оприходованное/разнесенное удалять.

[Kabardian]

Полностью согласен с тезизом "Заказы - черновики".

А можете поеделиться опытом, на скольких проектах из общего числа удалось уговорить пользователей на удаление заказов? Не обязательно абсолютные цифры указывать, можно в % от общего числа. Проекты на Axapta 3.0 не в счет из-за ограничений recid...

[Владимир Максимов]

Я правильно понял основную мысль:

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

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

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

[mazzy]

Zitat:

Zitat von Владимир Максимов

Если правильно, то, мягко выражаясь, не жирно ли будет? Как с точки зрения трудозатрат на эту модификацию

не жирно.
трудозатраты не слишком высокие, если знать фреймворк FormLetter.

Zitat:

Zitat von Владимир Максимов

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

Во-первых, не надо прикрываться пользователями. Мысль об "исходном документе" засевают консультанты.

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


В том то и дело:
заказ - черновик. Заказ - не исходный документ. Поэтому данные в заказах хранить нельзя. Фактические данные нужно протаскивать в документы. И уже документы, созданные на основании заказа, являются исходными документами.

[Ivanhoe]

Не люблю такую категоричность, но в целом согласен про Заказы-черновики, особенно для AX до 2009. А что делать, например, с заказами типа "Контракт"? А складские журналы с русской первичкой? А ТТН (waybill), печатная форма которого тянет данные из других документов и "черновиков"? А отсутствие нормального сторнирования накладной, когда заказа уже нет?

В AX 2012 с вводом версионности ряда документов-"черновиков" парадигма несколько сместилась, мне кажется. И, например, считать ли договор - черновиком? А Заявки на покупку?

[RVS]

Zitat:

Zitat von Владимир Максимов

Я правильно понял основную мысль:

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

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

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

О, черт.. куда я лезу.. тут - монстры бодаются..

==

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

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

[RVS]

Zitat:

Zitat von mazzy

нМысль об "исходном документе" засевают консультанты.

Mazzy, вопрос к Вам - снят..

[RVS]

Zitat:

Zitat von Владимир Максимов

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

Для того, чтобы печатать __печатные формы__ - есть __отдельные таблицы.. и Вы, и я их знаем..

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

Nothing anymore ))

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

[Kabardian]

Zitat:

Zitat von RVS

кто - на реальном клиенте -будед заниматься удалением заказов? Роль? Просто интересно, не видел ниразу такого (при этом я всеми руками за то , что так надо)..

Роль - системный администратор. Во многих модулях системы есть периодические операции по очистке данных.

[mazzy]

Zitat:

Zitat von Ivanhoe

А что делать, например, с заказами типа "Контракт"?

заказ типа "контракт" - это такой же черновик. только исполняется этот черновик другими заказами, которые в свою очередь исполняются фактическими документами. (пока не поглотит все вязкое трение (С) )

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

Zitat:

Zitat von Ivanhoe

А складские журналы с русской первичкой? А ТТН (waybill), печатная форма которого тянет данные из других документов и "черновиков"?

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

Zitat:

Zitat von Ivanhoe

А отсутствие нормального сторнирования накладной, когда заказа уже нет?

э-э-э? что имеется в виду?
копирование с минусом делается и на основании накладной.
конкретная реализация алгоритма? так см. рассуждения о локализации?
или еще чего?

Zitat:

Zitat von Ivanhoe

В AX 2012 с вводом версионности ряда документов-"черновиков" парадигма несколько сместилась, мне кажется.

хм... тут возможны разночтения. что именно имеется под "версионность ряда документов"?

Zitat:

Zitat von Ivanhoe

И, например, считать ли договор - черновиком? А Заявки на покупку?

договор - русский? который rcontract? ой, блин, это просто справочник "как в 1С".

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

Zitat:

Zitat von RVS

Mazzy, вопрос : а кто - на реальном клиенте -будед заниматься удалением заказов? Роль?

Zitat:

Zitat von Kabardian

Во многих модулях системы есть периодические операции по очистке данных.

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


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

Можно и нужно взводить эти галочки. тогда Аксапта сама при разноске будет удалять полностью разнесенные строчки и сокращать на разнесенное количество. В заказах останется только то, что осталось выполнить.

[Ivanhoe]

Zitat:

Zitat von mazzy

заказ типа "контракт" - это такой же черновик. только исполняется этот черновик другими заказами, которые в свою очередь исполняются фактическими документами. (пока не поглотит все вязкое трение (С) )

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

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

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

Zitat:

Zitat von mazzy

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

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

Zitat:

Zitat von mazzy

э-э-э? что имеется в виду?
копирование с минусом делается и на основании накладной.
конкретная реализация алгоритма? так см. рассуждения о локализации?
или еще чего?

Зачастую намного проще сделать сторно в том же заказе через немедленное получение. Но в целом, согласен, сейчас сторно более-менее допилили.

Zitat:

Zitat von mazzy

хм... тут возможны разночтения. что именно имеется под "версионность ряда документов"?

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

Zitat:

Zitat von mazzy

договор - русский? который rcontract? ой, блин, это просто справочник "как в 1С".

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

Zitat:

Zitat von mazzy

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

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

[EVGL]

Zitat:

Zitat von Ivanhoe

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

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

...

Видно, когда пишет практик. Соглашусь с каждым пунктом.

[mazzy]

Zitat:

Zitat von Ivanhoe

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

Эта логика подходит не только к контракту, но и к заказу.

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

Zitat:

Zitat von Ivanhoe

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

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

Zitat:

Zitat von Ivanhoe

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

абсолютно согласен.
Но это не повод не знать как именно было задумано изначально.

Zitat:

Zitat von Ivanhoe

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

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

Zitat:

Zitat von Ivanhoe

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

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

Zitat:

Zitat von Ivanhoe

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

историю в черновиках можно и не чистить.
но от этого черновики не перестают быть черновиками

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

я же сказал ровно то, что сказал: черновики (заказы) - могут удаляться. Поэтому данные в заказах хранить нельзя. Фактические данные нужно протаскивать в документы.

[RVS]

Zitat:

Zitat von Kabardian

Роль - системный администратор. Во многих модулях системы есть периодические операции по очистке данных.

Нет... админ - у него другая роль...

==

Мимо, работаем ))

[Vadik]

Zitat:

Zitat von Владимир Максимов

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

Нет ну всему же должен быть предел, в том числе и клиентоориентированности Пользователь хочет "как проще", проблемы аудита, целостности и непротиворечивости данных его не волнуют. Он сам поправит Ваш "исходный документ" (заказ) "как должно быть" а потом Вас же будет гонять "система №;%" и "печатные формы не сходятся". А Вы еще будете молиться чтобы на Ваши "исходные документы" в течение года-двух до окончания всевозможных аудитов никто не дышал. Так что - нет, не жирно, а "протаскивать", только так

[Владимир Максимов]

Zitat:

Zitat von mazzy

Во-первых, не надо прикрываться пользователями. Мысль об "исходном документе" засевают консультанты.

Я бы сказал наоборот. Мысль о "черновике" засевают программисты! Просто потому, что без постоянных отсылок к заказу проще программировать.

Zitat:

Zitat von mazzy

Во-вторых, еще раз:
* заказ можно разносить частично.

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

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

Zitat:

Zitat von mazzy

В том то и дело:
заказ - черновик. Заказ - не исходный документ. Поэтому данные в заказах хранить нельзя. Фактические данные нужно протаскивать в документы. И уже документы, созданные на основании заказа, являются исходными документами.

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

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

При таком подходе, естественно, ни о какой частичной разноске не может быть и речи. И частичная разноска воспринимается пользователем как нечто "не естественное". Не совпадают введенные и "бумажные" данные.

[Владимир Максимов]

Zitat:

Zitat von Vadik

Нет ну всему же должен быть предел, в том числе и клиентоориентированности Пользователь хочет "как проще", проблемы аудита, целостности и непротиворечивости данных его не волнуют. Он сам поправит Ваш "исходный документ" (заказ) "как должно быть" а потом Вас же будет гонять "система №;%" и "печатные формы не сходятся". А Вы еще будете молиться чтобы на Ваши "исходные документы" в течение года-двух до окончания всевозможных аудитов никто не дышал. Так что - нет, не жирно, а "протаскивать", только так

Не поправит. После разноски заказ блокируется. Запрет на редактирование. Кстати, эта возможность предусмотрена стандартным функционалом. Правда, по желанию (можно блокировать, а можно и не блокировать)

[RVS]

Блин.. вот читаю, то, что написали - умные люди.. и никак не пойму.. а зачем...

я - тупой (с)

===

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

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

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

==

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

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

==

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