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

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

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

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

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

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

[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

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

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

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

[Maxim Gorbunov]

Цитата:

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

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

Пользователям некогда, или всё же консультантам недосуг подумать о различных сценариях работы?

[RVS]

"я фигею, дорогая редакция..."

Это правда - или всерьез тут люди обсуждают - "а бывает ли частичная разноска заказа?"

===

Коллеги.. бывает, еще как - бывает.. и - кста - не бывает "частичной разноски заказа", бывает частичная отгрузка по заказу.. ну, со всеми вытекающими..

И это - нормальный, кстати, кусок нормального бузинесс-процесса...

==

Я - тупой (с)

[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

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

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

[EVGL]

Цитата:

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

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

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

...

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

[mazzy]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

[RVS]

Цитата:

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

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

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

==

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

[RVS]

Цитата:

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

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

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

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

Nothing anymore ))

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

[Vadik]

Цитата:

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

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

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

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

Цитата:

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

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

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