Доброго дня.

Помогите, пожалуйста, советом.

Задача.
Есть товары (Справочник), учёт товаров ведётся в РН (Вид: Остатки; Измерения: Товар, Склад, Полка, Состояние; Ресурсы: Количество).
Есть операция (пока Документ), которая двигает товары по складам и полкам.
Заказчик хочет, чтобы операция не сразу двигала товары, а создавала несколько промежуточных состояний товаров, типа (Резерв, В пути, Комплектация и прочее).
Но операция должна быть, и в операции кнопки: Резервировать, Отправить, Вернуть и прочее.
Например, создали операцию, добавили товаров, выбрали склады (откуда и куда) и полки, нажали "Резервировать", спустя несколько дней нажали "В путь", потом наконец нажали "Завершить". И все операции должны быть видны в учёте.

Как бы организовать это удобно для разработки и пользователя, но правильно с точки зрения учёта?

Спасибо.

Сделай измерение "Состояние товара"

(0) Как тебе удобнее так и делай. Можно отдельным регистром, можно в этом же РН отдельными ресурсами (как например в УТ сделано)

(0)(1) Я так понял, что оно уже есть?

(1) у него уже есть "Состояние", видимо, кавардак это не помогает разобрать.
(0) это вопрос методологии учёта и архитектуры данных. какой тип учёта важнее, насколько важно быстродействие тех или иных операций\чтений.
что-то (как резервы) можно вынести в отдельный РН и на выходе делать дельту между двумя остатками. в срезах последних по складу их будет видно, но контур резерва отделен от основного потока данных.
что-то (как процессы) можно копить в ресурсах материнского РН. то есть вычесть из основного ресурса колва и положить в соседний. в срезах последних их не будет видно, транзитные состояния влияют на основной поток данных.

(3) Да, состояние есть. Вопрос не в том как сделать это, а меня волнует промежуточное ведение РН, и в какой момент проводить документ (Операцию). То есть операция будет постоянно проводиться и менять состояние товаров, то клиент хочет чтобы была история всех состояний.

(5) Типовая история не поможет?

(5) Как это выглядит в глаза клиента? Что он хочет видеть?

(5) >> клиент хочет чтобы была история всех состояний
значит на каждую операцию нужен отдельный документ

(5) вопрос настолько общий что ответить на него можно обще. что собственно уже и сделали. Как конкретно сделать - зависит от кучи частностей именно по вашей компании/складу.

(7) вангую : чтобы можно было взять отчёт по РН и увидеть во сколько и куда катилась бочка спирта. приёмка, разгрузка, расчековка, разлив...

(8) +500!

(6)(7) Я полагаю, что нет. Хотят отчёты: что было отправлено и когда.

Клиент создал операцию, заполнил всё.
Нажал кнопку "Резерв".
Состояние товара (это как я думаю) поменялось с "Доступно" на "Резерв".
Про операцию "забыли" на время.
Товар в резерве.
Потом вспомнили, что у них там резерв, открыли операцию и нажали кнопку "В Путь".
Состояние товара поменялось с "Резерв" на "Товары в пути".
И так далее.
Потом клиент смотрит отчёт "Товары на складе", и хочет видеть на любой день какие товары в каком состоянии.

Мой вопрос я наверное не правильно сформулировал.
Попробую иначе сказать.
Как организовать проведение "Операции"?
Чтобы каждый раз все прошлые движения (от других состояний) тоже сохранялись в истории.

(10) В целом да

(12) у тебя "Состояние" это измерение. у тебя и так останется в движениях все установленные состояния. Что нужно еще то?

(5) см. (8) (10)

(8) Меня в какой момент посетила безумная идея, что на каждую кнопку нужна отдельная операция, которая клиенту будет не видна... О_о

(16) пилишь АРМ, который создаёт и проводит документы, по ходу работы с таблицей товаров в ТЗ на форме обработки.

(16) Можно просто в документе в дополнительной ТЧ хранить состояния с датой. Движения по остаткам с учетом этой ТЧ.

(14) Документ провели со статусом "Резерв": все товары получили состояние "Резерв". Потом тот же документ провели со статусом "В пути", все товары получили состояние "В пути". На сколько я понимаю про состояние резерв данных уже нет... Или я не правильно думаю?

(18) Хорошая идея. Я пока только историю состояний документа храню в ТЧ.

(0) "Операция" - смотрится странно, не думали о том, чтобы привязать эти операции к типовым документам. ЗаказПоставщику - в пути, ПоступлениеТиУ - на складе, ВнутреннийЗаказ - резерв, Перемещение - списано

(0) А кто у клиента является потребителем данной информации ?
кому для работы необходимо знать историю изменения статусов ?

(21) Клиент мыслит такими формулировками, в конфе "Операция", просто "Документ. И Клиент хочет одну операцию, чтобы там были все кнопки. Более того (не бейте меня) клиент хочет, чтобы одна операция (один Документ) делал всё.

Один документ "операция" - ручная ерунда, доп. действия, по смыслу напоминает блокнотик, только в базе. РН нужен, но не для состояний, как мне кажется РС. В РН остаток, в РС срез последних - текущее состояние товара, по связи получаем все необходимое. Движения в регистрах делают либо типовые документы, либо самописные, но это разные документы, отражающие стандартные хоз. операции

(22) Менеджеры складов, комплектовщики собирающие заказы, руководители хотят истории всех движений смотреть, инвентаризаций ещё...

(23)скажите ему, что можно обойтись без дополнительного документа совсем

(19) это если состояние в ресурсах у вас, а оно в измерениях.

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

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

(25) Регистр остатков не трогай
Создай РС, в нем меняй статусы
Насколько я понял по логике работы хотят лазать постоянно в заднее число и править документы - рс тебе поможет не ломать последовательности

(16) это не безумная а верная идея, как уже написали в 8 и 11
каждая операция проводится и фиксируется своим документом, возникает документ, автор, момент времени, состояние.
по карте возможных переходов разрешаем/блокируем кнопки на обработке, которыми проводятся дальнейшие операции - тоже с оформлением отдельных документов.
и по результатам собираем все это добро в отчетики.

(24) Интересно, но как-то сложно... Попробую ночью замоделировать.
(26) Не совсем понял вас.
(28) Тогда бы они остались в Excel... Задача стоит автоматизировать, красиво украсить и расшарить в интернет.
(29) Вот я и пришёл за советом, как бы мне красиво это изобразить.

Посоветуй заказчику УТ купить

(31) Спасибо. Попробую развить.

(33) Советовал. Смотрели. Хотят своё.

(32)озвучьте уже конфу, самописка? что то не увидел в теме упоминания об этом

(36) ОЙ. Простите. Самописная.

(31) А почему одним (документом) нельзя? И в одном регистре.
В док-те есть операция = состояние. А в регистре будет регистратор.
При проведении: предыдущая операция в минус, новая в плюс.
Чем не так?

(38) где предыдущая, а где текущая, в ТЧ? дата, операция, ответственный и т д

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

(39) Предыдущая - по остаткам. Текущая - в шапке (почему в ТЧ?).
Дата, ответственный и пр. = в регистраторе.

(38) Проблема в том, что один документ будет и резерв создавать, и в путь отправлять. То есть каждое проведение документа начинает каскад движений в РН.

а, понял о чем, ну мб, но один хрен, чепуха какая то, не в вашей идее, а в изначальной ситуации - РН, у него состояние какое то... например остаток на Склад: Склад1, Полка: Полка2, Состояние: ВПути. так в пути или уже на полке лежит, непонятно как то

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

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

(43) Действительно ерунда... Но это детали.

(45) Как у Стругацких: они хотели странного... Я с вами согласен. Ищу компромисс вот, чтобы и учёт верный выстроить и клиент был доволен.

(46) Как раз-таки нет.
А вообще, правильный подход: отчет - документ - справочник. То бишь отталкиваемся от отчета - что нужно видеть. И это (что нужно видеть) распихиваем в док-ты, справочники и пр.

(38) одним видом документов? да можно конечно.
а если одним экземпляром документа отрабатывать всё - возникнет ненужная сложность, и все наверняка сломается при каком то нештатном событии и придется мучительно разгребать код и данные.
это никак не сравнить с 5 простейшими документами, у каждого из которых свой этап, своя конкретная узкая задача и свой блок проведения в 5 строк.
и когда любая проблема с закрытыми глазами обнаруживается.

(44) Спасибо! Однозначно подтупливаю я что-то. Подумаю в этом направлении.

автор пилит адскую хрень.
в том смысле как он это излагает.
правильно излагает лодгер.
и нахрена складу видеть "в пути" - это м.б. интерес только для манагера обслуживающего эту сделку.

(49) Согласен. Думаете мне нравиться городить вот это вот всё?) У меня всё нутро болит от одной мысли, что перемещение заказчику и между склада в одном документе...

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

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

(44) + Для удобства работы клиента, как выше правильно говорил lodger, просто пилятся специализированные рабочие места, облегчающие принятие решений и автоматизирующие отражение хозяйственных операций (создание документов)

(51) В пути со склада да, нафик не надо. А вот в пути на склад... :))

(35) Они хотят свои АРМы. Это в разы проще/быстрее, с готовой архитектурой, чем ты свое УГ начнешь ща пилить. Если у тебя возникают вопросы как (0), мягко говоря 10 раз подумай, прежде чем лезть в архитектуру

(56) это да. хотя бы для того чтобы озаботиться и с зоны приемки растащить все барахло

(0)  > (Вид: Остатки; Измерения: Товар, Склад, Полка, Состояние; Ресурсы: Количество).

Если не нужен учет по Заказам по которым происходит резервирование то можно тупо добавить соответствующие ресурсы.

Если нужен, тогда делать еще один регистр.

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

если типовую купить не хотят, то надо сделать как в типовой своими силами, варианты реализации в (0) и остальным постам тс - уг

Всем спасибо за ваше время.

Если товар в пути,то это склад=машина
Чем вам тут состояние поможет.
Со склада А погрузили в машину то есть склад М и перемещаем,а потом со склада М доставили на склад Б.
Состояние может помочь только в размещении по полкам,да и тут заводится вмртуальная полка "Куча в углу" и нет проблем.

И комплектация также,товар с полки взяли в корзину - перемещение и т.п.