Создание Штраф\Ремонт записей

[hodkovdd]

from @sedovalx to @hodkoff2 Кстати, по поводу самих Штраф/Ремонт записей. А не это не то же самое внешне, как если б мы создавали отрицательный платеж за штраф или ремонт? Если так, то это можно довольно просто реализовать на клиенте. Или вообще оставить как есть. По первому времени не обломятся, думаю, будут минус указывать в операции.

[sedovalx]

Это что такое?

[hodkovdd]

@sedovalx то что ты предлагаешь, это костыль. Однако может сработать. У формы создания Штраф\Ремонт записей есть обязательное поле Описание нарушения\повреждения, а также в будущем появиться связанное поле фотография. В форме Платежа есть поле Явка, которое не к месту в штрафах\списаниях:

[hodkovdd]

1. нужно понять нужно ли городить костыль или сразу сделать разные формы. Так ли это сложно?

[sedovalx]

Все это ерунда, если б не обязательность поля с описанием. В операции тоже есть поле с комментарием, но оно не обязательно. А так почти один в один, что платежи, что сами ремонты и штрафы. Только знак числа отличается. Галку с явкой можно легко скрыть. Но ты прав, лучше сделать раздельные сущности. Операции разделить на платежи и списания. В принципе, это не очень сложно. Один свободный вечер для доделки сервера и пара вечеров для клиента. Поле явки нужно только для платежа за аренду? Платежи за штраф и ремонты без явки происходят?

[sedovalx]

@hodkoff2 а все же, давай пофантазируем. Ниже перечислю сходства списаний и платежей:

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

Ничего не упустил? С этой точки зрения и платежи, и списания - это суть операции просто с разным знаком суммы и разными обязательными описаниями.

[sedovalx]

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

[hodkovdd]

@sedovalx Ты предлагаешь расширить количество свойств сущности настолько, чтобы в нее помещались и платежи и списания. Я примерно так себе и представил твою идею. С точки зрения наполнения ок, мы их занесли и балансы считаются верно просто по сумме чисел. А когда придется извлекать, например для сводной таблицы по конкретной аренде, получится красиво их распарсить на платежи, списания, ремонты, штрафы? В целом вопрос такой - будут ли ограничения по манипуляциям этими записями после их занесения в базу если мы свалим их в одну кучу? Насколько высоки будут накладные расходы на проверки что это за запись при извлечении (не станет ли подтормаживать та же сводная таблица по аренде спустя полгода год, когда накопятся данные) ?

Ничего не упустил?

• Тип операции (аренда, штраф, ремонт)

Поле явки нужно только для платежа за аренду? Заполненное поле явка означает, что водитель приехал и показал машину. Сделать он это может и не оплатив аренду. Таким образом поле явка нужно для всех видов платежей.

[sedovalx]

У каждой операции есть тип: аренда, штраф, ремонт. Добавляем сюда знак операции и получаем:

• Платеж за аренду
• Платеж за штраф
• Платеж за ремонт
• Ремонт
• Штраф

Что за сводная таблица по аренде?

[hodkovdd]

@sedovalx обсуждалось здесь: https://github.com/sedovalx/taxi/issues/76

[hodkovdd]

@sedovalx Чтобы не громоздить кучу ненужных кнопок в интерфейсе КС как это сделано сейчас: можно ли сделать создание операции через унифицированную форму как на дизайн-схеме был задуман платеж: только с поправкой на то что мы обсудили выше:

:

[sedovalx]

Да в общем-то можно. Только не лучше ли сделать две кнопки:

• Создать платеж
• Создать списание и избавиться от первой формы? @Argelein ты как считаешь?

[kirzas]

@hodkoff2 @sedovalx да, давайте так сделаем. ощущение хождения по кругу имеется :) тогда это будет как и раньше открытие формы с выбором типа платежа. А от того, выбрано списание или платеж, будет зависеть знак перед суммой, верно? т.е. в интерфейсе и при создании платежа и при создании списаний удет положительная сумма, но на сервер будет уходить со знаком + или -, в зависимости от того, по какой кнопке перешли из кассовой формы. Я правильно понял?

[hodkovdd]

@Argelein @sedovalx "...т.е. в интерфейсе и при создании платежа и при создании списаний удет положительная сумма, но на сервер будет уходить со знаком + или -, в зависимости от того, по какой кнопке перешли из кассовой формы..." - по мне да, Саша, согласен?

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

[sedovalx]

@hodkoff2 @Argelein Да, вроде бы все так. В кассовой форме нужно сделать две кнопки:

• Создать платеж
• Создать списание

По нажатию должен открываться редактор операции с полями:

• Тип операции (платеж или списание). Нередактируемое.
• Аренда. Нередактируемое.
• Дата операции. Текущее время. Нередактируемое.
• Тип баланса. Для списания - это штрафы и ремонты. Для платежей - это аренда, штрафы и ремонты.
• Сумма
• Описание
• файлы... (пока не делаем)

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

Путь: $/cashier-list/rents/12/operations/new?type=plus (или minus)

[sedovalx]

Входит в план-минимум #95

[kirzas]

@hodkoff2 @sedovalx Проверьте, пожалуйста, все ли как вы планировали. Я пока закрываю. Если что переоткройте.

[hodkovdd]

@Argelein поля "явка" в форме "Charge" (новое списание) не должно быть. Значение False должно быть зашито. Поле "явка" в форме "Payment" (новый платеж) сейчас не меняет значение в колонке Явка в КС. Почему?

[kirzas]

@hodkoff2 а может быть платеж без явки? может строго пришить явку к типу операции? платеж - явка true, списание - явка false?

[hodkovdd]

@Argelein платеж можно передать через другого водителя, оставить в почтовом ящике в конверте и прочее. Другими словами платеж может быть с явкой и без нее. У списания явки вообще не должно быть, это просто последствие того что мы платежи и списание храним в одной сущности "операция".

[kirzas]

@hodkoff2 @sedovalx сейчас в модели явка по умолчанию true предлагаю такой вариант:

1. явка по умолчанию false;
2. в платеже ее можно поставить руками;
3. в списании она readonly

устраивает?

[sedovalx]

@Argelein в UI списания поле явки должно быть скрыто. Какое значение явки по умолчанию должно быть при создании платежа, путь скажет @hodkoff2.

[hodkovdd]

@Argelein значение явки по умолчанию должно быть при создании платежа - false - пусть ручками ставит, подтверждая, что явка была.

[kirzas]

@hodkoff2 @sedovalx На клиенте сделал, осталось это:

Поле "явка" в форме "Payment" (новый платеж) сейчас не меняет значение в колонке Явка в КС. Это на сервере надо сделать ведь?

[sedovalx]

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

[kirzas]

@sedovalx нормально уходит "presence: true": operation: {changeTime: "2015-07-21T20:55:55.622Z", amount: 44, accountType: "Rent", rentDisplayName: null,…} accountType: "Rent" amount: 44 changeTime: "2015-07-21T20:55:55.622Z" comment: null creationDate: null creator: null editDate: null editor: null operationType: "payment" presence: true rent: "94" rentDisplayName: null Еще один момент придумал, но заведу на это дела две других задачи.