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

[mazzy]

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

Цитата:

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

Цитата:

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

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

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

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

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

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

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

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

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

[MikeR]

Цитата:

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

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


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

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

[gl00mie]

Цитата:

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

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

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

[Kabardian]

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

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

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

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

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

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

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

[mazzy]

Цитата:

Сообщение от Владимир Максимов

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

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

Цитата:

Сообщение от Владимир Максимов

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

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

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


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

[RVS]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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

[sukhanchik]

Цитата:

Сообщение от Владимир Максимов

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

Есть такой функционал в системе, как скидки по оплате. Раньше я тоже считал, что это "не для России", пока не увидел, как этим пользуются и когда это востребовано.
Частичная разноска реально востребована. В каком-то смысле я даже наоборот скажу - мне довелось видеть ситуаций / компаний, где не была она востребована - гораздо меньше, нежели ситуаций, когда она востребована.
Правда тут есть оговорка - речь идет о заказах на покупку.
В случае заказов на продажу - действительно чаще его разносят целиком. Но опять-таки - это вопрос методологии использования.
Если заказ клиента воспринимать, как заказ того, чего он хочет купить - то возникают ситуации с доставкой товара клиенту. Хорошо, когда у нас сразу есть все в наличии.

А теперь берем ситуацию: Клиент хочет купить у нас чего-то, согласно списку (заказу). Из, допустим 20 позиций - у нас в достаточном количестве есть только 15, еще 2 позиции есть, но в недостаточном количестве, а 3-х просто нет. Мы заинтересованы все же отгрузить клиенту весь заказ и мы знаем, что мы можем отгрузить, но просто на данный момент еще не весь заказ готов. А клиенту нужно купить у нас срочно в первую очередь именно те позиции, которые у нас есть, а остальные он покупает что называется "до кучи". Мы ему с радостью отгрузим то, что ему жизненно необходимо и пообещаем потом "довезти" и довезем. Мы также понимаем, что при нашем отказе отгрузить клиенту товар хотя бы частично - клиент может и сорваться.
Конечно эту ситуацию можно решить через отдельные заказы; через копирование заказов и т.д., воспринимая заказ на продажу, как одну накладную Торг-12. Но по факту-то это не так. По факту-то был один заказ, просто он раздробился. И дробя заказы - мы теряем связь с родительским заказом. Ну или надо кодить связку. Существующий функционал частичной отгрузки позволяет видеть в системе реальное количество именно заказов клиентов, а не "преднакладных".

А теперь возвращаемся к вопросу анализа данных. Бумажные данные - это накладные. Введенные данные - это данные от звонка / email-а клиента. Эту разницу должны понимать люди, анализирующие эти данные. Если они эту разницу не понимают или им не нужно понимать (например, никогда не может возникнуть такой ситуации в отдельно взятой компании) - то вполне логично, что тут можно опираться и на данные заказа. Их еще будет раздражать промежуточная форма разноски и вообще сам факт ввода данных не в таблице накладных .

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

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

Цитата:

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

А теперь берем ситуацию: Клиент хочет купить у нас чего-то, согласно списку (заказу). Из, допустим 20 позиций - у нас в достаточном количестве есть только 15, еще 2 позиции есть, но в недостаточном количестве, а 3-х просто нет. Мы заинтересованы все же отгрузить клиенту весь заказ и мы знаем, что мы можем отгрузить, но просто на данный момент еще не весь заказ готов. А клиенту нужно купить у нас срочно в первую очередь именно те позиции, которые у нас есть, а остальные он покупает что называется "до кучи". Мы ему с радостью отгрузим то, что ему жизненно необходимо и пообещаем потом "довезти" и довезем. Мы также понимаем, что при нашем отказе отгрузить клиенту товар хотя бы частично - клиент может и сорваться.

Конечно эту ситуацию можно решить через отдельные заказы; через копирование заказов и т.д., воспринимая заказ на продажу, как одну накладную Торг-12. Но по факту-то это не так. По факту-то был один заказ, просто он раздробился. И дробя заказы - мы теряем связь с родительским заказом. Ну или надо кодить связку. Существующий функционал частичной отгрузки позволяет видеть в системе реальное количество именно заказов клиентов, а не "преднакладных".

Описана в чистом виде организационная проблема. В смысле, выбранный способ решения. Точка зрения на проблему...

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

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

Цитата:

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

А теперь возвращаемся к вопросу анализа данных. Бумажные данные - это накладные. Введенные данные - это данные от звонка / email-а клиента. Эту разницу должны понимать люди, анализирующие эти данные.

Угу. Разделение заказов на "предварительные" (журнал) и окончательные (заказ) снимает эту проблему и еще кучу сопутствующих.

[Maxim Gorbunov]

Цитата:

Сообщение от Владимир Максимов

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

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

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

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

Цитата:

Сообщение от Maxim Gorbunov

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

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

И совершенно не вызывает удивления тот факт, что мультиварку начинают использовать как обычную кастрюлю... Ну, в лучшем случае, как скороварку...

[RVS]

Цитата:

Сообщение от Владимир Максимов

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

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

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

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

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

==

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

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

[Kabardian]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

Цитата:

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

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

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


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

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

[Ivanhoe]

Цитата:

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

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[RVS]

Цитата:

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

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

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

==

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

[RVS]

Цитата:

Сообщение от Владимир Максимов

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

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

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

Nothing anymore ))

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

[Vadik]

Цитата:

Сообщение от Владимир Максимов

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

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

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

Цитата:

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

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

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