Тест работает или не работает? Что-то отхлебнуло.

Тест работает или не работает? Что-то отхлебнуло.

Хочу протестировать, работает или нет запись голоса.

Хочу протестировать, работает или нет запись голоса.

Тест тестов

Тест тестов

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

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

И я вижу, что ты уже где-то в комментариях поставил на коробку true или false, на каркас true или false. Мне кажется, целый отдельный проект будет разгруппировать все, что мы считаем, на какие-то элементарные истории, отделочные материалы, фрезеровки, там у нас операции через по сборке каркаса, например, что мы его у себя собираем. Ну, короче, есть куча маленьких элементарных операций, и у нас интерфейс должен быть понятный, чтобы мы могли просто галочками некими чекбоксами, на может кнопками, кинут красивыми по порядку сказать: отгрузить просто профиль, а все остальное - спецификацию показать, чтоб человек собирал или профиль распилить и отфрезеровать и скомплектовать комплектующими, пусть дальше делает, что хочет. Ну, как бы, разная есть комбинация.

И я вижу, что ты уже где-то в комментариях поставил на коробку true или false, на каркас true или false. Мне кажется, целый отдельный проект будет разгруппировать все, что мы считаем, на какие-то элементарные истории, отделочные материалы, фрезеровки, там у нас операции через по сборке каркаса, например, что мы его у себя собираем. Ну, короче, есть куча маленьких элементарных операций, и у нас интерфейс должен быть понятный, чтобы мы могли просто галочками некими чекбоксами, на может кнопками, кинут красивыми по порядку сказать: отгрузить просто профиль, а все остальное - спецификацию показать, чтоб человек собирал или профиль распилить и отфрезеровать и скомплектовать комплектующими, пусть дальше делает, что хочет. Ну, как бы, разная есть комбинация.

Так, давай уточним по сервису Type Duration, ведь у нас есть тобой уже в операциях раскроя. Мы же с тобой уже там фиксировали время, какое-то необходимое на раскрой. Может быть, нам нужна небольшая база данных, которая описывает операции: она точно у нас скорее всего уже есть, и там должно стоять временно выполнение операции, хотя бы некий норматив. Потом поймешь, нас разные сотрудники в разное время делают, но базовый математический норматив должен быть задан, чтобы мы могли от него потом уже смотреть, что куда происходит.

Так, давай уточним по сервису Type Duration, ведь у нас есть тобой уже в операциях раскроя. Мы же с тобой уже там фиксировали время, какое-то необходимое на раскрой. Может быть, нам нужна небольшая база данных, которая описывает операции: она точно у нас скорее всего уже есть, и там должно стоять временно выполнение операции, хотя бы некий норматив. Потом поймешь, нас разные сотрудники в разное время делают, но базовый математический норматив должен быть задан, чтобы мы могли от него потом уже смотреть, что куда происходит.

Дальше, создавая заказ из расчета материалов, я понимаю, что нам надо в заказе хранить ссылку, из какого расчета это все создано было. То есть у нас получается три точки истины: это спецификация, где мы описали конечный результат, который мы хотим, это у нас вот этот расчет, который мы сделали, сколько всего надо. Этот расчет, не сказать, что он является базой для заказа. Они, скорее всего, где-то наравне по уровню подчиненности. Но, короче, заказ может из расчета быть заполнен. То есть, если считать, что у нас заказы формируются через связь с номенклатурой и получают туда объекты, то это просто удобный способ заполнить заказ. Но хорошо бы иметь связь, чтобы потом можно было к расчетам вернуться, посмотреть, как это кроить. Да и мы можем для клиентов суперсервис сделать, что мы вместе с заказом, всегда с любым, который мы рассчитали, мы можем дать им спецификацию, как это все делать, какие размеры материалов им потребуются. Особенно мне важно, кроме раскроя профилей, дать людям и размеры панелей, которые нужны для сборки этих дверей. Вот я размеры знаю, я тебе их скидывал когда-то, мы их просто немножко уточним и где-то в сервисе к ним будем ссылаться. Потому что мы знаем, что алюминиевый каркас высоты 2000 мм требует от нас высоту 1994 мм по лицевой стороне. А если модули Q или D применяются, там свои формулы немножко, но это тоже где-то хранится, это можно найти. Так мы можем им выдавать, какого размера панели нужны для той или иной двери, на лицевую и на обратную сторону, с учетом всех модулей, используемых.

Дальше, создавая заказ из расчета материалов, я понимаю, что нам надо в заказе хранить ссылку, из какого расчета это все создано было. То есть у нас получается три точки истины: это спецификация, где мы описали конечный результат, который мы хотим, это у нас вот этот расчет, который мы сделали, сколько всего надо. Этот расчет, не сказать, что он является базой для заказа. Они, скорее всего, где-то наравне по уровню подчиненности. Но, короче, заказ может из расчета быть заполнен. То есть, если считать, что у нас заказы формируются через связь с номенклатурой и получают туда объекты, то это просто удобный способ заполнить заказ. Но хорошо бы иметь связь, чтобы потом можно было к расчетам вернуться, посмотреть, как это кроить. Да и мы можем для клиентов суперсервис сделать, что мы вместе с заказом, всегда с любым, который мы рассчитали, мы можем дать им спецификацию, как это все делать, какие размеры материалов им потребуются. Особенно мне важно, кроме раскроя профилей, дать людям и размеры панелей, которые нужны для сборки этих дверей. Вот я размеры знаю, я тебе их скидывал когда-то, мы их просто немножко уточним и где-то в сервисе к ним будем ссылаться. Потому что мы знаем, что алюминиевый каркас высоты 2000 мм требует от нас высоту 1994 мм по лицевой стороне. А если модули Q или D применяются, там свои формулы немножко, но это тоже где-то хранится, это можно найти. Так мы можем им выдавать, какого размера панели нужны для той или иной двери, на лицевую и на обратную сторону, с учетом всех модулей, используемых.

По разделу 5 у меня вопрос есть, если мы в будущем будем какие-то изменения вносить в код или в модель расчета спецификаций, то сможет ли это у нас все корректно хранится в джейсоне? Я вообще за то, чтобы у нас все хранилось в моделях, потому что я очень понимаю, где она лежит, как она лежит, как она хранится, как не доступ получить джейсон. Я переживаю, что если мы изменим структуру данных когда-то, то джейсон и перестанут подходить и все сломается. А модели проще редактировать, на мой взгляд. Мы с тобой не совсем MVP разрабатываем, мы разрабатываем с тобой рабочую версию, которая у нас работает.

По разделу 5 у меня вопрос есть, если мы в будущем будем какие-то изменения вносить в код или в модель расчета спецификаций, то сможет ли это у нас все корректно хранится в джейсоне? Я вообще за то, чтобы у нас все хранилось в моделях, потому что я очень понимаю, где она лежит, как она лежит, как она хранится, как не доступ получить джейсон. Я переживаю, что если мы изменим структуру данных когда-то, то джейсон и перестанут подходить и все сломается. А модели проще редактировать, на мой взгляд. Мы с тобой не совсем MVP разрабатываем, мы разрабатываем с тобой рабочую версию, которая у нас работает.

Вопрос у меня к тебе, к модели сервис type для фрезеровок, почему я спрашиваю тебя? У нас же есть услуги, которые мы клиенту продаем, а есть операции на производстве, и не знаем, где что и как ты делишь. Но у нас есть услуга, например, фрезеровка петли, или еще лучше пример - распил профиля. Операции мы с тобой в раскрою считаем: это положить профиль, установить раль ганг, установить угол пилы, флип профиля. Вот эта операция элементарная, мы их тоже можем в секундах оценить. И получается, у нас в итоге под обработку профиля мы можем посчитать, сколько времени уходит, зная, сколько операции надо сделать. И услуга там, раскрою профиля, можно ее очень точно оценить, что услуга по раскрою профиля - 40 минут. И мы знаем, наверное, что себестоимость у нас часа сотрудника там определенная, наверно, зафиксировано нас в сервисе в юнит экономики, мы фиксируем, типа 750 рублей в час. Понимаем, за сколько можем продавать, чтобы какую-то норму прибыли обеспечить. Понимаем стоимость одной себестоимости, одной услуги, исходя из того, что она из операции складывается. И можем прогнозировать еще и время выполнения заказа. То есть, со всех сторон одни плюсы.

Вопрос у меня к тебе, к модели сервис type для фрезеровок, почему я спрашиваю тебя? У нас же есть услуги, которые мы клиенту продаем, а есть операции на производстве, и не знаем, где что и как ты делишь. Но у нас есть услуга, например, фрезеровка петли, или еще лучше пример - распил профиля. Операции мы с тобой в раскрою считаем: это положить профиль, установить раль ганг, установить угол пилы, флип профиля. Вот эта операция элементарная, мы их тоже можем в секундах оценить. И получается, у нас в итоге под обработку профиля мы можем посчитать, сколько времени уходит, зная, сколько операции надо сделать. И услуга там, раскрою профиля, можно ее очень точно оценить, что услуга по раскрою профиля - 40 минут. И мы знаем, наверное, что себестоимость у нас часа сотрудника там определенная, наверно, зафиксировано нас в сервисе в юнит экономики, мы фиксируем, типа 750 рублей в час. Понимаем, за сколько можем продавать, чтобы какую-то норму прибыли обеспечить. Понимаем стоимость одной себестоимости, одной услуги, исходя из того, что она из операции складывается. И можем прогнозировать еще и время выполнения заказа. То есть, со всех сторон одни плюсы.

Что касается раздела 2, исправления в текущем коде: к модуль, конечно, высота к модуля минус 5 миллиметров, тут все верно. Мы с тобой и ширину верно размышляем. Вопрос, что у нас же и слева на полотне, и справа на полотне, к модуль есть, сверху есть и снизу есть. Иногда мы верхние и нижней меняем на д модуль. Короче, надо не ошибиться в количестве, которое применяется на полотне. Но я думаю, твоей логике для этого хватит.

Что касается раздела 2, исправления в текущем коде: к модуль, конечно, высота к модуля минус 5 миллиметров, тут все верно. Мы с тобой и ширину верно размышляем. Вопрос, что у нас же и слева на полотне, и справа на полотне, к модуль есть, сверху есть и снизу есть. Иногда мы верхние и нижней меняем на д модуль. Короче, надо не ошибиться в количестве, которое применяется на полотне. Но я думаю, твоей логике для этого хватит.

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

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

Еще у нас есть позиции, которые не фигурируют в спецификации. У нас есть отдельный модуль, который устанавливает соответствие между разной номенклатурой, но возможно, при переезде, там, с базы данных на базу данных, какие-то связи потерялись. Но мы знаем, что там, к определенным профилям, определенные петли подходят. У нас, в интерфейсе спецификации, она показывается. Потом, у нас есть уплотнители, уплотнитель указ 110, дробь 3.4, подходит к нашим профилям всем, то есть, совместимость можно поставить. И по цвету, дополнения, есть алюминиевые сухари, сухарь размера 30 миллиметров на 12, подходит к нашим системам, например, чтобы собрать одно дверное полотно, 4, 2 на 2 метра высоты дверной коробки, на одну сторону, на две стороны, 6, и пропорциональное количество растет, нам вверх. То есть, этот список комплектующих, которые явно в спецификации не фигурируют, но по умолчанию, как бы, участвовать в сборке дверей, тоже надо к этому подбить и подготовить. Еще есть один момент, как вторую задачу, можно добавить: у нас на системе Джон Голд, на нашей основной, используется Q и D модуля. Вот, мы сейчас, в раскрое, не считали, в сервисе Q 5, 2000, 45 Q 1995, ширина двери 800, то мы Q-модуль, по ширине, запиливаем 795 миллиметров, такой раскрой. Если у нас, сверху и снизу, применяется D-модуль, то у него ширина тоже уменьшается, 20 миллиметров. И у Q-модуля, в будущем, будет отдельная длина, пока, мы ее не можем вычислить математически, только на практике, вычислили. Когда Q-модуль стыкуется с D-модулем, то у Q-модуля длина другая, не на 5 мм меньше. Но неизвестно, какая. Пока можно считать, по такой же формуле, как просто, для ситуации, когда Q-модули по периметру располагаются. Но заложить сразу, что мы потом цифры поменяем в формуле.

Еще у нас есть позиции, которые не фигурируют в спецификации. У нас есть отдельный модуль, который устанавливает соответствие между разной номенклатурой, но возможно, при переезде, там, с базы данных на базу данных, какие-то связи потерялись. Но мы знаем, что там, к определенным профилям, определенные петли подходят. У нас, в интерфейсе спецификации, она показывается. Потом, у нас есть уплотнители, уплотнитель указ 110, дробь 3.4, подходит к нашим профилям всем, то есть, совместимость можно поставить. И по цвету, дополнения, есть алюминиевые сухари, сухарь размера 30 миллиметров на 12, подходит к нашим системам, например, чтобы собрать одно дверное полотно, 4, 2 на 2 метра высоты дверной коробки, на одну сторону, на две стороны, 6, и пропорциональное количество растет, нам вверх. То есть, этот список комплектующих, которые явно в спецификации не фигурируют, но по умолчанию, как бы, участвовать в сборке дверей, тоже надо к этому подбить и подготовить. Еще есть один момент, как вторую задачу, можно добавить: у нас на системе Джон Голд, на нашей основной, используется Q и D модуля. Вот, мы сейчас, в раскрое, не считали, в сервисе Q 5, 2000, 45 Q 1995, ширина двери 800, то мы Q-модуль, по ширине, запиливаем 795 миллиметров, такой раскрой. Если у нас, сверху и снизу, применяется D-модуль, то у него ширина тоже уменьшается, 20 миллиметров. И у Q-модуля, в будущем, будет отдельная длина, пока, мы ее не можем вычислить математически, только на практике, вычислили. Когда Q-модуль стыкуется с D-модулем, то у Q-модуля длина другая, не на 5 мм меньше. Но неизвестно, какая. Пока можно считать, по такой же формуле, как просто, для ситуации, когда Q-модули по периметру располагаются. Но заложить сразу, что мы потом цифры поменяем в формуле.

У меня есть одна задача, большая, я бы даже сказал, толстая, небольшая, она просто содержит кучу маленьких задач, которые надо как-то очень рационально выполнить, разумно. У нас есть модуль, где мы заносим данные о дверях клиентов, все позиции, которые там есть, это объекты, на которые есть ссылка в базы данных, в УРМ объекта: фурнитура, профиля, отделочные материалы и код. Вопрос нам бы подготовить список всех материалов, которые участвуют в производстве двери, и всех услуг, которые там есть. Под материал я понимаю алюминиевый профиль, петли, замки, уплотнитель, например, это не явно, но там существует начали, но можно более явно сделать, но пусть так, мы понимаем, что просто есть определенный уплотнитель, который к определенному профилю подходит. Вот есть отделочные материалы, лицевые, сложность состоит в том, что, например, для дверей, чтобы посчитать количество профиля, надо обратиться к сервису расчета раскроя, мы в целом туда уже данные передаем и считать раскрой умеем и можем понимать, сколько профиля надо, раскрой делается сложно, бачим сразу на всю спецификацию, на каждую дверь, поэтому на каждую конкретную дверь количество материала извлечь достаточно трудно, но возможно, я думаю, каким-то образом, но тоже указаны какие размеры полотна, мы знаем, они у нас видны, и то есть мы можем понять, какого размера облицовочные материалы нужны на эту дверь, у нас даже где-то формулы есть расчета размера облицовочных материалов под конкретную модификацию каркаса дверного полотна, учитывая, что у нас там сверху Д-модули или снизу могут быть по краям Q-модули, это влияет на размеры, но там все понятно, вычисляемо. И самое, может быть, не очевидно, но количество услуг тоже можно посчитать, у нас есть количество петель, например, мы знаем, что есть фрезеровка под петли в дверной коробке и фрезеровка под петли в каркасе дверного полотна, под замок тоже делается фрезеровка, под ответную планку делается фрезеровка, если есть выпадающие пороге или доводчики, тоже есть фрезеровка, количество услуг пилы мы можем посчитать из раскрою мини во профиля, мы потому что знаем, сколько раз там надо пройтись пилой, чтобы это все распилить, так можем посчитать количество услуг и товаров, и даже показать конкретно, какие товары участвуют, какие услуги участвуют, которые участвуют в раскрое, и показал мне списком вообще все, что мы можем сейчас извлечь. В итоге мы должны с тобой проработать ЮАЙ и X для страницы, которую бы показала все материалы и все услуги, которые участвуют в создании этой двери и всей спецификации конкретной двери. Если по конкретной двери мы не можем посчитать точное количество профиля, но мы же знаем количество деталей из раскроя, можем количество деталей указать, или суммарное количество метров, можем даже где-то округлить, сайт, вот количество метров, а количество обрезков профиля можем равномерно распределить между всеми позициями, например, или пропорционально объему профиля на дверь, или показать, сколько чистого профиля надо, и в итоге показать, сколько хлыстов надо всего, ну короче, надо все исследовать глубоко, предложить архитектуру страницы, которая показала бы все исходники, которые нужны для двери, это нам надо, чтобы дать людям спецификацию, с чего соберется дверь, и итоговую цену, а потом, чтобы можно было счет на оплату сформировать, исходя из того, что мы знаем, какие позиции использовались и сколько их штук. Ну и в конечном итоге мы поймем реальную себестоимость двери по материалам, просто с облицовочными материалами возможно будет не так просто, мы можем очень грубо пока сказать, сколько стоит МДФ-панель за квадратный метр и покраска за квадратный метр, а реально высчитать расходы грамм и краски мы пока не можем, у нас столько данных нет точных, но по раскрою профиля мы можем точные данные дать, потому что у нас уже есть сервис, который это считает, и очевидно, то, что у нас есть сейчас сервис по раскрою, это будет вторая задача, надо сделать так, чтобы история раскроя в хранилась, мы уже научились туда в раскрою конкретной спецификации вставлять, она знает, какой там профиль, какие размеры дверей и считает, но как только мы страницу покидаем, она забывает, какие были с к ю кей в алюминиевого профиля, какой длины там же разные есть, разные можно использовать, а надо, чтобы она это все сохраняла, историю каждого расчета по сути, расчет для спецификации хранится, или может просто свободный расчет хранится без всяких данных, надо уметь хранить историю расчетов, вот у меня к тебе такая задача, давай ее разберем по шагам, глубоко проанализируем, и в итоге надо показать интерфейс, который сможет нам собрать вообще все материалы, которые нужны для спецификации, и по каждой позиции материалы сгруппировать, сколько надо.

У меня есть одна задача, большая, я бы даже сказал, толстая, небольшая, она просто содержит кучу маленьких задач, которые надо как-то очень рационально выполнить, разумно. У нас есть модуль, где мы заносим данные о дверях клиентов, все позиции, которые там есть, это объекты, на которые есть ссылка в базы данных, в УРМ объекта: фурнитура, профиля, отделочные материалы и код. Вопрос нам бы подготовить список всех материалов, которые участвуют в производстве двери, и всех услуг, которые там есть. Под материал я понимаю алюминиевый профиль, петли, замки, уплотнитель, например, это не явно, но там существует начали, но можно более явно сделать, но пусть так, мы понимаем, что просто есть определенный уплотнитель, который к определенному профилю подходит. Вот есть отделочные материалы, лицевые, сложность состоит в том, что, например, для дверей, чтобы посчитать количество профиля, надо обратиться к сервису расчета раскроя, мы в целом туда уже данные передаем и считать раскрой умеем и можем понимать, сколько профиля надо, раскрой делается сложно, бачим сразу на всю спецификацию, на каждую дверь, поэтому на каждую конкретную дверь количество материала извлечь достаточно трудно, но возможно, я думаю, каким-то образом, но тоже указаны какие размеры полотна, мы знаем, они у нас видны, и то есть мы можем понять, какого размера облицовочные материалы нужны на эту дверь, у нас даже где-то формулы есть расчета размера облицовочных материалов под конкретную модификацию каркаса дверного полотна, учитывая, что у нас там сверху Д-модули или снизу могут быть по краям Q-модули, это влияет на размеры, но там все понятно, вычисляемо. И самое, может быть, не очевидно, но количество услуг тоже можно посчитать, у нас есть количество петель, например, мы знаем, что есть фрезеровка под петли в дверной коробке и фрезеровка под петли в каркасе дверного полотна, под замок тоже делается фрезеровка, под ответную планку делается фрезеровка, если есть выпадающие пороге или доводчики, тоже есть фрезеровка, количество услуг пилы мы можем посчитать из раскрою мини во профиля, мы потому что знаем, сколько раз там надо пройтись пилой, чтобы это все распилить, так можем посчитать количество услуг и товаров, и даже показать конкретно, какие товары участвуют, какие услуги участвуют, которые участвуют в раскрое, и показал мне списком вообще все, что мы можем сейчас извлечь. В итоге мы должны с тобой проработать ЮАЙ и X для страницы, которую бы показала все материалы и все услуги, которые участвуют в создании этой двери и всей спецификации конкретной двери. Если по конкретной двери мы не можем посчитать точное количество профиля, но мы же знаем количество деталей из раскроя, можем количество деталей указать, или суммарное количество метров, можем даже где-то округлить, сайт, вот количество метров, а количество обрезков профиля можем равномерно распределить между всеми позициями, например, или пропорционально объему профиля на дверь, или показать, сколько чистого профиля надо, и в итоге показать, сколько хлыстов надо всего, ну короче, надо все исследовать глубоко, предложить архитектуру страницы, которая показала бы все исходники, которые нужны для двери, это нам надо, чтобы дать людям спецификацию, с чего соберется дверь, и итоговую цену, а потом, чтобы можно было счет на оплату сформировать, исходя из того, что мы знаем, какие позиции использовались и сколько их штук. Ну и в конечном итоге мы поймем реальную себестоимость двери по материалам, просто с облицовочными материалами возможно будет не так просто, мы можем очень грубо пока сказать, сколько стоит МДФ-панель за квадратный метр и покраска за квадратный метр, а реально высчитать расходы грамм и краски мы пока не можем, у нас столько данных нет точных, но по раскрою профиля мы можем точные данные дать, потому что у нас уже есть сервис, который это считает, и очевидно, то, что у нас есть сейчас сервис по раскрою, это будет вторая задача, надо сделать так, чтобы история раскроя в хранилась, мы уже научились туда в раскрою конкретной спецификации вставлять, она знает, какой там профиль, какие размеры дверей и считает, но как только мы страницу покидаем, она забывает, какие были с к ю кей в алюминиевого профиля, какой длины там же разные есть, разные можно использовать, а надо, чтобы она это все сохраняла, историю каждого расчета по сути, расчет для спецификации хранится, или может просто свободный расчет хранится без всяких данных, надо уметь хранить историю расчетов, вот у меня к тебе такая задача, давай ее разберем по шагам, глубоко проанализируем, и в итоге надо показать интерфейс, который сможет нам собрать вообще все материалы, которые нужны для спецификации, и по каждой позиции материалы сгруппировать, сколько надо.

прием прием работает или нет

прием прием работает или нет

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

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

У нас есть домены в номенклатуре, один из них - это hardware или компонент. Изучи внимательно: у нас где-то уже было проработано, где будут храниться уплотнители, в каком доме, не им даже единиц измерения были спроектированы, и вообще, бухты и учет длины и все вот эти моменты. И мы все же можем прайс подготовить для них. Я сейчас цены дам, а ты пока разберись связями, как сделать так, чтобы уплотнители оказались у нас в базе данных. Посмотри, какие цвета есть уплотнителей на сайте контура, или может быть, кто-то перепродает их уплотнители в интернете, и у них есть раскладка, какие цвета существуют. Тоже надо будет базу данных заполнить, но адекватными цветами, не мусором каким-то. Поэтому перед заполнением утверди со мной.

У нас есть домены в номенклатуре, один из них - это hardware или компонент. Изучи внимательно: у нас где-то уже было проработано, где будут храниться уплотнители, в каком доме, не им даже единиц измерения были спроектированы, и вообще, бухты и учет длины и все вот эти моменты. И мы все же можем прайс подготовить для них. Я сейчас цены дам, а ты пока разберись связями, как сделать так, чтобы уплотнители оказались у нас в базе данных. Посмотри, какие цвета есть уплотнителей на сайте контура, или может быть, кто-то перепродает их уплотнители в интернете, и у них есть раскладка, какие цвета существуют. Тоже надо будет базу данных заполнить, но адекватными цветами, не мусором каким-то. Поэтому перед заполнением утверди со мной.

посмотри пожалуйста знаешь на что я вижу что ты не все увидел в модели данных у нас например покрытие уже в спецификациях выбираются у нас есть и система профилей и автоматически какие профиля там применяются и там это все работает через связи с базами данных то есть это не какой-то hard код то есть там по идее все уже есть аж финальная цель это чтобы мы в get в интерфейсе ввели вводные нас это ввели данные дверей а на выходе получили из каких компонентов она состоит Но нам промежуточно надо поставить галочки, что мы клиенту предлагаем. Дверную коробку окей, каркас окей, замки, петли, что мы в расчет считаем. И от того, какие галочки стоят, получается, формируется список того, что ему надо и в каком количестве. Достаточно простая задача, не просто потому что тебе надо разобраться со структурой базы данных, что откуда тянется. И как это все посчитать.

посмотри пожалуйста знаешь на что я вижу что ты не все увидел в модели данных у нас например покрытие уже в спецификациях выбираются у нас есть и система профилей и автоматически какие профиля там применяются и там это все работает через связи с базами данных то есть это не какой-то hard код то есть там по идее все уже есть аж финальная цель это чтобы мы в get в интерфейсе ввели вводные нас это ввели данные дверей а на выходе получили из каких компонентов она состоит Но нам промежуточно надо поставить галочки, что мы клиенту предлагаем. Дверную коробку окей, каркас окей, замки, петли, что мы в расчет считаем. И от того, какие галочки стоят, получается, формируется список того, что ему надо и в каком количестве. Достаточно простая задача, не просто потому что тебе надо разобраться со структурой базы данных, что откуда тянется. И как это все посчитать.

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

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

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

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

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

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

Еще есть задача, смотри: мы с тобой посчитали спецификацию для двери, мы подготовили. У нас есть итог, который мы считаем очевидно, он где-то в базе данных сохраняется. Так вот, вопрос: что нам бы в этой базе данных, ну или как-то, я не знаю, как сохранить, посчитать, сколько вообще чего надо на эту дверь, профиля, понятно. Мы через свой сервис раскроя посчитаем. Вот, например, уплотнитель: его должно быть столько же, сколько метров дверной коробки, например, количество петель, количество замков, надо посчитать. Можем мы как-то всю эту информацию в одном месте собрать, потому что нам потом, если мы не готовую дверь делаем, готовим счет на оплату по всем номенклатурам, которые у нас есть, надо будет сумму собрать всех компонентов, которые нам нужны. Как это сделать, я пока не очень понимаю, но понимаю, что с той базы, которой мы подготовили, это возможно. Исследую проект, предложи варианты, как это сделать. Тем более, мы обсуждали, что вот мы на дверь спецификацию накидали, она у нас по факту из кучи компонентов состоит, в итоге они все имеют связи с ураем нашей, и мы можем просто количество компонентов, которые нужны на изготовление двери, показывать. Generally, потом их и закинуть в счет на оплату и продать клиентам построчно.

Еще есть задача, смотри: мы с тобой посчитали спецификацию для двери, мы подготовили. У нас есть итог, который мы считаем очевидно, он где-то в базе данных сохраняется. Так вот, вопрос: что нам бы в этой базе данных, ну или как-то, я не знаю, как сохранить, посчитать, сколько вообще чего надо на эту дверь, профиля, понятно. Мы через свой сервис раскроя посчитаем. Вот, например, уплотнитель: его должно быть столько же, сколько метров дверной коробки, например, количество петель, количество замков, надо посчитать. Можем мы как-то всю эту информацию в одном месте собрать, потому что нам потом, если мы не готовую дверь делаем, готовим счет на оплату по всем номенклатурам, которые у нас есть, надо будет сумму собрать всех компонентов, которые нам нужны. Как это сделать, я пока не очень понимаю, но понимаю, что с той базы, которой мы подготовили, это возможно. Исследую проект, предложи варианты, как это сделать. Тем более, мы обсуждали, что вот мы на дверь спецификацию накидали, она у нас по факту из кучи компонентов состоит, в итоге они все имеют связи с ураем нашей, и мы можем просто количество компонентов, которые нужны на изготовление двери, показывать. Generally, потом их и закинуть в счет на оплату и продать клиентам построчно.

Счете надо всегда указывать данные о НДС, даже если это без НДС, потому что людям важно, как они оплачивают, и неважно. И поэтому, или кто там для пешки до 2 пешки, мы должны по умолчанию ставить без НДС, например, в интерфейсе в нашем, чтобы оператору было удобней работать, потому что наша и пышка не является платежиком DS. Давай разберемся с логикой вообще отображение цены всего остального у нас. Счете сейчас сумма 11000, 214 рублей в интерфейсе, а в PDF ки отображается 13 с чем-то тысяч рублей. Тут где-то что-то некорректно. У нас в счете должна быть или сумма с НДС AM показана, она там сейчас НДС AM показана, сумма без НДС 9100, с НДС 2022, Итого 11214. Почему в счете оказывается 13681, непонятно. Разберись внимательно. Это очень чувствительные данные. И здесь надо быть корректным.

Счете надо всегда указывать данные о НДС, даже если это без НДС, потому что людям важно, как они оплачивают, и неважно. И поэтому, или кто там для пешки до 2 пешки, мы должны по умолчанию ставить без НДС, например, в интерфейсе в нашем, чтобы оператору было удобней работать, потому что наша и пышка не является платежиком DS. Давай разберемся с логикой вообще отображение цены всего остального у нас. Счете сейчас сумма 11000, 214 рублей в интерфейсе, а в PDF ки отображается 13 с чем-то тысяч рублей. Тут где-то что-то некорректно. У нас в счете должна быть или сумма с НДС AM показана, она там сейчас НДС AM показана, сумма без НДС 9100, с НДС 2022, Итого 11214. Почему в счете оказывается 13681, непонятно. Разберись внимательно. Это очень чувствительные данные. И здесь надо быть корректным.

Еще посмотри внимательно, у нас когда мы нажимаем печать PDF, почему-то перестали туда передаваться поля из заказа, номенклатура, позиции, все. Если есть рез профиля, то рез профиля, мы с тобой это проектировали, обрабатывали. Почему-то до шаблона, который выдается в печатной форме, у нас не дошло, надо, чтобы доходило.

Еще посмотри внимательно, у нас когда мы нажимаем печать PDF, почему-то перестали туда передаваться поля из заказа, номенклатура, позиции, все. Если есть рез профиля, то рез профиля, мы с тобой это проектировали, обрабатывали. Почему-то до шаблона, который выдается в печатной форме, у нас не дошло, надо, чтобы доходило.

у спецификации двери у меня есть много вопросов во-первых кнопка которая в списке спецификации позволяет добавить в архив по идее должна быть корзиной а сделки которые мы убрали в архив не должны отображаться в этом списке второе ты можешь посмотреть как устроена страница с списком ордерсов и сверстать здесь такую же важно чтобы могли разные столбики делать видимыми или невидимыми и менять их местами дальше зайдем в конкретные заказы и увидим там внутри тоже много проблем что у нас у заказа у спецификации Посмотри, пожалуйста, как у нас обрабатываются параметры по умолчанию, которые есть. Система профилей, которую мы выбираем по умолчанию, цвет профиля, шумоизоляция. они у нас в целом по настройкам сервис уже должен быть предустановлены всегда когда мы открываем создание новой спецификации сейчас они не установлены по умолчанию плюсом к этому когда они по умолчанию установлено когда мы каждую новую строчку добавляем позиции спецификации с дверями все параметры которые здесь по умолчанию и туда тоже должны по умолчанию заноситься то есть система профилей и цвет профиля и шумоизоляция еще у нас где-то особняком в этой всей истории всегда работает лицевая сторона и обратная сторона не знать как это устроено в коде но почему-то сколько мы ее с кодом не обрабатываем она всегда где-то в стороне 4 4 4 покрытие поэтому хотелось бы их иметь пред заполненными всегда дальше есть проблема с тем когда у нас выбрана фурнитура 3 петли например сейчас стоит для двери большого размера и третья петля у нас в базе данных почему-то хранится как 2297 рублей это не очень корректно потому что изначально там сумма была другая я могу поискать может и сам найдешь 4500 рублей примерно было логика такая что когда мы вставляем петлю у нас есть фрезеровка в коробке и фрезеровка в каркасе полотна поэтому есть петля плюс услуги поэтому петля стоит не как стоимость петли а дополнительно надо эту логику исследовать и поправить вот ну и с версткой что-то не так и вместо попав какая-то ничь постоянно открывается хорошо бы спроектировать по папы не то чтобы с нуля но вот все что у нас есть в карточках когда мы разворачиваем эту позицию вот эти все карточки переверстать туда как по папы то есть можно я даже просто синхронизировать как это можно синхронизировать на уровне кода я не очень понимаю ну и каждая строчка не имеет там верстки сейчас кнопки отобразить в кнопки скопировать или удалить куда-то это верстки пропала вот хочу чтобы ты шаг за шагом разобрался сначала посмотрела все проблемы, исследовал весь код, понял взаимосвязи, которые есть и предложил решение. Решения должны быть такие, чтобы не хардкодить, а максимально гибко все устроить, чтобы это все работало с разными связями и нормально все отрабатывалось.

у спецификации двери у меня есть много вопросов во-первых кнопка которая в списке спецификации позволяет добавить в архив по идее должна быть корзиной а сделки которые мы убрали в архив не должны отображаться в этом списке второе ты можешь посмотреть как устроена страница с списком ордерсов и сверстать здесь такую же важно чтобы могли разные столбики делать видимыми или невидимыми и менять их местами дальше зайдем в конкретные заказы и увидим там внутри тоже много проблем что у нас у заказа у спецификации Посмотри, пожалуйста, как у нас обрабатываются параметры по умолчанию, которые есть. Система профилей, которую мы выбираем по умолчанию, цвет профиля, шумоизоляция. они у нас в целом по настройкам сервис уже должен быть предустановлены всегда когда мы открываем создание новой спецификации сейчас они не установлены по умолчанию плюсом к этому когда они по умолчанию установлено когда мы каждую новую строчку добавляем позиции спецификации с дверями все параметры которые здесь по умолчанию и туда тоже должны по умолчанию заноситься то есть система профилей и цвет профиля и шумоизоляция еще у нас где-то особняком в этой всей истории всегда работает лицевая сторона и обратная сторона не знать как это устроено в коде но почему-то сколько мы ее с кодом не обрабатываем она всегда где-то в стороне 4 4 4 покрытие поэтому хотелось бы их иметь пред заполненными всегда дальше есть проблема с тем когда у нас выбрана фурнитура 3 петли например сейчас стоит для двери большого размера и третья петля у нас в базе данных почему-то хранится как 2297 рублей это не очень корректно потому что изначально там сумма была другая я могу поискать может и сам найдешь 4500 рублей примерно было логика такая что когда мы вставляем петлю у нас есть фрезеровка в коробке и фрезеровка в каркасе полотна поэтому есть петля плюс услуги поэтому петля стоит не как стоимость петли а дополнительно надо эту логику исследовать и поправить вот ну и с версткой что-то не так и вместо попав какая-то ничь постоянно открывается хорошо бы спроектировать по папы не то чтобы с нуля но вот все что у нас есть в карточках когда мы разворачиваем эту позицию вот эти все карточки переверстать туда как по папы то есть можно я даже просто синхронизировать как это можно синхронизировать на уровне кода я не очень понимаю ну и каждая строчка не имеет там верстки сейчас кнопки отобразить в кнопки скопировать или удалить куда-то это верстки пропала вот хочу чтобы ты шаг за шагом разобрался сначала посмотрела все проблемы, исследовал весь код, понял взаимосвязи, которые есть и предложил решение. Решения должны быть такие, чтобы не хардкодить, а максимально гибко все устроить, чтобы это все работало с разными связями и нормально все отрабатывалось.

Первое, что не работает, это в списке заказов: у нас есть кнопка "удалить", вот она не консистентно всему остальному сервису. Дальше, когда мы открываем конкретный заказ с Эльвином, какая-то большая история - заказ 2-1-1, там почему-то и нормально не подгружаются и название компании, и контакт. Но если создать новый заказ, в целом там все нормально, подгружается; единственное, по моему, когда идет разговор о оплате и мы принимаем оплату на банковскую карту, и заказ автоматически сохраняется, то сервис теряет информацию о том, на какую карту был принят заказ, и вообще не факт, что это в базу данных все сохраняется. MD, в итоге, в таблице позиций некорректно отображается, потом в самом позициях между ценой и суммой стоит слэш - штук, это некорректно, там этого не должно быть; у нас количество единиц измерения уже указаны в столбики "количество", и в доставке, когда выбираем получателя в выпадающем списке, должно быть по левому краю выровнено - все они так, как сейчас, вот разбит все на задачи. Посмотри, разберись, почему так, и давай все приведем в порядок. Если где-то у нас, когда мы выбираем банк, у нас стандартная меню, которую нам дает операционной системы или браузер, все-таки хотелось бы иметь выпадающие списки, как у нас во всем сервисе, чтобы все было консистентно, и чтобы сохранение работало адекватно, постоянно. Что-то сделали, сама сохранилась, и в клиентах мы в отображении потеряли у юрлица после перезагрузки страницы возможность поменять юрлицо и контакт - а это раньше было у нас доступно; может быть, это можно увидеть в прошлых комитах.

Первое, что не работает, это в списке заказов: у нас есть кнопка "удалить", вот она не консистентно всему остальному сервису. Дальше, когда мы открываем конкретный заказ с Эльвином, какая-то большая история - заказ 2-1-1, там почему-то и нормально не подгружаются и название компании, и контакт. Но если создать новый заказ, в целом там все нормально, подгружается; единственное, по моему, когда идет разговор о оплате и мы принимаем оплату на банковскую карту, и заказ автоматически сохраняется, то сервис теряет информацию о том, на какую карту был принят заказ, и вообще не факт, что это в базу данных все сохраняется. MD, в итоге, в таблице позиций некорректно отображается, потом в самом позициях между ценой и суммой стоит слэш - штук, это некорректно, там этого не должно быть; у нас количество единиц измерения уже указаны в столбики "количество", и в доставке, когда выбираем получателя в выпадающем списке, должно быть по левому краю выровнено - все они так, как сейчас, вот разбит все на задачи. Посмотри, разберись, почему так, и давай все приведем в порядок. Если где-то у нас, когда мы выбираем банк, у нас стандартная меню, которую нам дает операционной системы или браузер, все-таки хотелось бы иметь выпадающие списки, как у нас во всем сервисе, чтобы все было консистентно, и чтобы сохранение работало адекватно, постоянно. Что-то сделали, сама сохранилась, и в клиентах мы в отображении потеряли у юрлица после перезагрузки страницы возможность поменять юрлицо и контакт - а это раньше было у нас доступно; может быть, это можно увидеть в прошлых комитах.

Тут, в этом сервисе, уже некая штука применена, ее не очень видно, но поиск по профилям под капотом содержит, что мы к базе данных прицепили к каждой ячейке, которую у нас есть: роль, название профиля, название системы, цвет, покрытия, цвета, например, еще и связанные названиями человеческими у профилей, у петель, у разных производителей петель - их собственные коды, потом человекочитаемое название. У каждого поля в базе данных появилась соседняя ячейка, которая посчитала векторное значение этого параметра. Когда мы в поиск вводим какие-то слова или словосочетания, для этих слов тоже считается векторное значение, и сортировка результатов поиска идет по этим вектором, там, конечно, много еще при сортировке весов участвуют в ранжировании, там и частотность использования в предыдущих, пользователи не особо видим эту магию, но поиск и поиск, а то, что она по короткому введенному значению дает максимально релевантные результаты, это кусочек современной магии. Так вот, у меня есть мысль, что если нормально структурировать данные, и не только о профилях, но о них в первую очередь, это предметное знание наше о дверях, профилях, материалах, отделочных, потом большим массивом загонять телефонные разговоры и переписки, то можно помогать менеджеру готовить максимально релевантные ответы на каждый запрос человека. В перспективе сделать так, что во время прямого эфира, в разговоре с клиентом, менеджеру будут показываться подсказки, куда вести диалог дальше и какие-то актуальные вещи. Если это получится сделать, можно полететь в космос.

Тут, в этом сервисе, уже некая штука применена, ее не очень видно, но поиск по профилям под капотом содержит, что мы к базе данных прицепили к каждой ячейке, которую у нас есть: роль, название профиля, название системы, цвет, покрытия, цвета, например, еще и связанные названиями человеческими у профилей, у петель, у разных производителей петель - их собственные коды, потом человекочитаемое название. У каждого поля в базе данных появилась соседняя ячейка, которая посчитала векторное значение этого параметра. Когда мы в поиск вводим какие-то слова или словосочетания, для этих слов тоже считается векторное значение, и сортировка результатов поиска идет по этим вектором, там, конечно, много еще при сортировке весов участвуют в ранжировании, там и частотность использования в предыдущих, пользователи не особо видим эту магию, но поиск и поиск, а то, что она по короткому введенному значению дает максимально релевантные результаты, это кусочек современной магии. Так вот, у меня есть мысль, что если нормально структурировать данные, и не только о профилях, но о них в первую очередь, это предметное знание наше о дверях, профилях, материалах, отделочных, потом большим массивом загонять телефонные разговоры и переписки, то можно помогать менеджеру готовить максимально релевантные ответы на каждый запрос человека. В перспективе сделать так, что во время прямого эфира, в разговоре с клиентом, менеджеру будут показываться подсказки, куда вести диалог дальше и какие-то актуальные вещи. Если это получится сделать, можно полететь в космос.

Ну, и мысли у меня есть: это же можно, если она даже материалы понимает - облицовочные, и может размеры считать этих материалов. То даже когда клиент у нас комплект профиля покупает, мы ему можем выдать полную спецификацию. Во-первых, из каких материалов это собирать, какие должны быть размеры в раскрое, заказаны там уже. Мы близки к тому, чтобы позиционировать замок, петли на профиль размещать, потому что замках она знает все: где какие там бэксеты, язычки и центр язычка, и вот это все, и размеры двери знает, спецификация, то есть, посчитать облицовочный материал какого размера, где что устанавливается, какие отверстия делаются. И еще, для профиля это нам, наверно, важно, если мы комплект готовим, но и им тоже может быть полезно. Еще для профиля имеет последовательность обработки, с учетом того, что мы понимаем, как удобнее на пиле что-то делать, как удобнее переворачивать, какой процесс удобный, и что в алгоритм эти вещи зашиты, то это становится уже неким конструктором, где просто по инструкции шаг за шагом все собираешь. А еще и стоимость труда людей считается, еще и стоимость менеджеров считается, когда в рукопашную это делать не надо. Ну, и колоссальное снижение интеллектуальной рутины, количество.

Ну, и мысли у меня есть: это же можно, если она даже материалы понимает - облицовочные, и может размеры считать этих материалов. То даже когда клиент у нас комплект профиля покупает, мы ему можем выдать полную спецификацию. Во-первых, из каких материалов это собирать, какие должны быть размеры в раскрое, заказаны там уже. Мы близки к тому, чтобы позиционировать замок, петли на профиль размещать, потому что замках она знает все: где какие там бэксеты, язычки и центр язычка, и вот это все, и размеры двери знает, спецификация, то есть, посчитать облицовочный материал какого размера, где что устанавливается, какие отверстия делаются. И еще, для профиля это нам, наверно, важно, если мы комплект готовим, но и им тоже может быть полезно. Еще для профиля имеет последовательность обработки, с учетом того, что мы понимаем, как удобнее на пиле что-то делать, как удобнее переворачивать, какой процесс удобный, и что в алгоритм эти вещи зашиты, то это становится уже неким конструктором, где просто по инструкции шаг за шагом все собираешь. А еще и стоимость труда людей считается, еще и стоимость менеджеров считается, когда в рукопашную это делать не надо. Ну, и колоссальное снижение интеллектуальной рутины, количество.

Мысль у меня все та же, это во всем приложении ко всем таблицам в базе данных прицепить векторные поля, и на любой запрос, который к нашему сервису приходит, отдавать релевантные данные для ответа. Эти релевантные данные - это некий набор информации, который будет подаваться как prompt для LLM, и она будет помогать. Структурируя данные, которые есть, и объединяя близкие по смыслу в какие-то списки, и создавала большую память для внешних LLM-систем. Сначала попробуем просто сильно повысить качество ответов, потом их доточить, чтобы они на продаже влияли. А потом хочу соединить это все с телефонным звонком, чтобы в прямом эфире готовить для менеджера, что ему дальше говорить клиенту, и совсем апофеозом этой истории должно стать, что мы можем пойти к инвесторам, начать выступать на сцене и показать, что мы с ними разговариваем с помощью этого суфлера. Такой план может быть, по ходу что-то изменится, но базовая вот так вижу.

Мысль у меня все та же, это во всем приложении ко всем таблицам в базе данных прицепить векторные поля, и на любой запрос, который к нашему сервису приходит, отдавать релевантные данные для ответа. Эти релевантные данные - это некий набор информации, который будет подаваться как prompt для LLM, и она будет помогать. Структурируя данные, которые есть, и объединяя близкие по смыслу в какие-то списки, и создавала большую память для внешних LLM-систем. Сначала попробуем просто сильно повысить качество ответов, потом их доточить, чтобы они на продаже влияли. А потом хочу соединить это все с телефонным звонком, чтобы в прямом эфире готовить для менеджера, что ему дальше говорить клиенту, и совсем апофеозом этой истории должно стать, что мы можем пойти к инвесторам, начать выступать на сцене и показать, что мы с ними разговариваем с помощью этого суфлера. Такой план может быть, по ходу что-то изменится, но базовая вот так вижу.

У нас сейчас будет супер задача по супер экономии токенов, чтобы выполнить то, что нам надо выполнить, и потратить как можно меньше. Подумай, как-то лучше организовать, можешь ответы свои сжать, муж, еще что-то, но надо до сути добраться. У нас есть вот эти спецификации, отдельно есть модуль, которые готовят, раскрою профиля, пока если нам важно на ошибку не напороться, мы будем работать вокруг профильной системы Джон Голд 45, она есть в базе моделей. Какая задача, мы сейчас в сервис раскроя, там тоже выбирается профильная система, коробка, каркас, дверного платна, можно вставить размеры, какого размера дверь мы хотим, и все сервис делает раскрой и считает. Так вот, надо наладить какой-то мост между спецификациями и сервисом раскроя, чтобы каждую спецификацию, которую мы создавали, для нее был какой-то выпадающий список в сервисе раскроя, ITEMS, мы тоже с тобой там такой интерфейс имеем. Выбирается профильная система. Мы сейчас в спецификациях только на одной профильной системе считаем, это Джон Голд. И сервис раскроя у нас оптимизирован под этот Джон Голд. Поэтому тут конфликта возникнуть не должно. Я уверен, что у нас сервис Раскрой сейчас принимает объекты из ОРМ Джанго, из базы данных. И сервис, который готовит спецификации, тоже оперирует этими же моделями. То есть, если мы в сервисе Раскрой сделаем выбодающий список всех спецификаций, то в целом это будет работать. Q D, потому что они установлены в сервисе раскроя правила, какой размер профиля нужен под ту или иную дверь. Но я думаю, что это мы допилим немного позже, а базовую уже можно одно в другое передать. У нас с тобой осталось очень мало контекста. Предложи решение этой задачи, как его можно решить и не сломать. Я думаю, что у нас в сервисе спецификации ничего меняться не должно, кроме какой-то кнопки, которая позволяет нам перейти в сервис раскроя и посмотреть там результаты. Вот создана спецификация.

У нас сейчас будет супер задача по супер экономии токенов, чтобы выполнить то, что нам надо выполнить, и потратить как можно меньше. Подумай, как-то лучше организовать, можешь ответы свои сжать, муж, еще что-то, но надо до сути добраться. У нас есть вот эти спецификации, отдельно есть модуль, которые готовят, раскрою профиля, пока если нам важно на ошибку не напороться, мы будем работать вокруг профильной системы Джон Голд 45, она есть в базе моделей. Какая задача, мы сейчас в сервис раскроя, там тоже выбирается профильная система, коробка, каркас, дверного платна, можно вставить размеры, какого размера дверь мы хотим, и все сервис делает раскрой и считает. Так вот, надо наладить какой-то мост между спецификациями и сервисом раскроя, чтобы каждую спецификацию, которую мы создавали, для нее был какой-то выпадающий список в сервисе раскроя, ITEMS, мы тоже с тобой там такой интерфейс имеем. Выбирается профильная система. Мы сейчас в спецификациях только на одной профильной системе считаем, это Джон Голд. И сервис раскроя у нас оптимизирован под этот Джон Голд. Поэтому тут конфликта возникнуть не должно. Я уверен, что у нас сервис Раскрой сейчас принимает объекты из ОРМ Джанго, из базы данных. И сервис, который готовит спецификации, тоже оперирует этими же моделями. То есть, если мы в сервисе Раскрой сделаем выбодающий список всех спецификаций, то в целом это будет работать. Q D, потому что они установлены в сервисе раскроя правила, какой размер профиля нужен под ту или иную дверь. Но я думаю, что это мы допилим немного позже, а базовую уже можно одно в другое передать. У нас с тобой осталось очень мало контекста. Предложи решение этой задачи, как его можно решить и не сломать. Я думаю, что у нас в сервисе спецификации ничего меняться не должно, кроме какой-то кнопки, которая позволяет нам перейти в сервис раскроя и посмотреть там результаты. Вот создана спецификация.

Вопрос по структуре этой модели: зачем вообще в ней что-то хранится о оплатах? У нас же оплаты скорее всего где-то в другом месте обрабатываются. Может быть, вообще из этой модели эти поля удалить, к хуям? Что думаешь? У нас просто оплата есть, конкретного ордера, заказа, то есть к ордером привязанной оплаты. А и спецификацией, спецификация с оплатами вообще сейчас никак не связано. Спецификация будет подтягиваться в ордерсы через подключение через номенклатуру, и оплата будет фиксироваться по конкретному ордерсу, у которого есть связь с спецификацией. Понимаешь, то есть у спецификации вообще не надо ничего про оплаты хранить, только про цены, она может что-то знать.

Вопрос по структуре этой модели: зачем вообще в ней что-то хранится о оплатах? У нас же оплаты скорее всего где-то в другом месте обрабатываются. Может быть, вообще из этой модели эти поля удалить, к хуям? Что думаешь? У нас просто оплата есть, конкретного ордера, заказа, то есть к ордером привязанной оплаты. А и спецификацией, спецификация с оплатами вообще сейчас никак не связано. Спецификация будет подтягиваться в ордерсы через подключение через номенклатуру, и оплата будет фиксироваться по конкретному ордерсу, у которого есть связь с спецификацией. Понимаешь, то есть у спецификации вообще не надо ничего про оплаты хранить, только про цены, она может что-то знать.