Собственно, об этом и был долгий разговор. Стоит ли учить именно британской версии произношении, если в остальном мире это скорее всего воспринимается именно в "подразумеваемом" смысле.
В итоге сошлись на том, что сын уже достаточно взрослый чтобы объяснить.
Камрады видимо сидят на УСН (Доходы минус расходы 15%) и за счёт страховых взносов и возможных льгот имеют ~7% Ок.
Мы пока на НДС не попали, но это вопрос времени
По 176ФЗ камрадам нужно будет платить 5% при обороте >60 млн. При обороте 2,5 млн с партии НДС 5% = 125т.₽ сверху, которые либо убьют заявленную маржу, либо придётся повышать цену и получать снижения спроса. На этот оборот они по цифрам (мы же им верим?) вот-вот выйдут, то есть вопрос стоит остро.
И тут возникает момент, который камрады видимо постеснялись упомянуть :)) Им неоткуда платить этот НДС: - при контрабанде карго-ввозе нет входного НДС (нет ГТД), а значит нет права на вычет, то есть те самые 5% платить нужно, а вычесть нечего. - НДС платится с отгрузок, а деньги от маркетплейса приходят с задержкой 7–14 дней. Нужен оборотный капитал, которого нет. Типовой кассовый разрыв.
Вариантов у них особо нет, либо дробить бизнес (ещё большие риски, которых и так хватает. Там в статье заявлена ещё покупка отзывов в явном виде, а это ещё пара статей, если по-серьёзному домотаться), либо уходить на ОСНО в белую, а с их маржой ~4 это глубокий минус.
Чёт есть ощущение, что тут не только маркетплейсы виноваты ))))))
Да, разумеется. И 1-я линия ТП на трубе с персоналом магазина скорее всего не дойдут до этого. Но инциденты с кассами - это по дефолту высокий приоритет, а значит до 3-й линии инцидент долетит очень быстро. И там пришлют штрихкоды, сбросят и настроят заново.
Ну ок. За 10 минут я конечно слишком оптимистично заявил :)))))
Да, привычка - дело реально серьёзное. Просто интересно стало. Я бы покурил с заказчиком этот вопрос, попадись мне такая задача. Дело тут даже не в мобильности рабочего места. На ТСД сам UI нативнее для таких задач.
Там другие минусы типа интеграции с Эской в недрах склада, глухие зоны wifi, обрывы коннекта и прочие неприятности
Про сканера - да, разумеется. Подавляющее большинство моделей настраиваются служебными штрихкодами.
Насчёт вектора атаки - я реально в ступоре. Можете придумать кейс? Ну допустим Вы на кассе самообслуживания в условной Пятерочке отсканировали 3 штрихкода (кстати, для этого модель их сканера нужно знать). Режим программирования - запрет чтения датаматрикс - сохранение настроек. Ну перестала касса на некоторое время пробивать кефир и прочий Честный знак. Пока поддержка руками директора магазина не сбросила сканер в дефолт и не вернула настройки. Дел на 10 минут.
Ну а дальше идёт вызов наряда, съём данных с камер и привет минимум административка за хулиганство. Причём не отвертишься никак. Штрихкоды специальные, умысел докажет любой первокурсник с юрфака.
Если кто-то покажет сканеру любой штрихкод из методички по программированию (а не только коды для перевода в режим эмуляции клавиатуры и обратно в Com), то хорошо проинструктированный суровый начальник смены оторвёт ему руки.
Так - работает. Многократно проверено.
В сторону ТСД вообще не смотрели? Любопытно зачем оставили моноблоки, если по-любому софт допилиливали?
10000 / 30 дней / 12 рабочих часов - это примерно 1 выдача в 2 минуты. Конвейер.
Я не буду спорить с Вашей математикой, своей по-любому нет. Но у меня паззл не сошёлся.
В целом логика, которую Вы привели абсолютно рабочая, розничные продуктовые сети тоже от оборота на количество жителей вокруг точки раньше считали. Но цифры мне кажутся странными
Если совсем коротко, то да. При превышении лимита мест хранения и скорости выдачи, ПВЗ просто нельзя выбрать для доставки. Если интересно, можно помониторить вал таких отключений при приближении крупного праздника типа 8 марта.
По отношению к покупателям тут с одной стороны, да. Наличие лимита - это неудобно. С другой стороны
- в ПВЗ в основном используется ячеечная система хранения, которая обеспечивает высокую скорость и точность выдачи. Сотрудник не ковырятся полчаса в мешках в поисках заказа. Это для покупателя положительно. Зашел-забрал
- в ПВЗ ограничено количество сотрудников. При условной норме обслуживания 3 минуты на заказ, больше 20 заказов на час на точку распределять нельзя - будет очередь и беготня
Я имею в виду, что "лимиты" - обычное ограничение процесса. Но могут использоваться не только по прямому назначению :)
В данном случае требования к методу обработки уже детерменированы, не меняются от запуска к запуску и их формулирование не дается на откуп модели в инференсе.
То, что промпт написан с применением LLM, в данном случае не играет сильной роли. Это малая автоматизация, почему бы и нет, если результат проверен. Важнее то, что на входе есть стабильный фиксированный перечень требований.
Разумеется, это не даёт 101% гарантии, но минимум иллюзия управляемости уже есть
Вдогонку к предыдущему, не успел за время редактирования.
Нашёл пример для DrawIO. Загнал под спойлер
Пример
Палитра Arhimate
Кусок промпта:
# Задача Для описанного процесса составь Archimate-диаграмму уровня процесса в виде mxGraphModel XML для экспорта в DrawIO.
# Справочник стилей Archimate 3.0 (DrawIO) Используй строго эти параметры для атрибута style. ВАЖНО: Все элементы используют shape=mxgraph.archimate3.application. Слой определяется цветом.
# Правила генерации XML 1. Shape: Для ВСЕХ вершин используй shape=mxgraph.archimate3.application (не меняй на business/technology). 2. Стиль вершины: html=1;outlineConnect=0;whiteSpace=wrap;fillColor={цвет};shape=mxgraph.archimate3.application;appType={тип};archiType={форма}; Если archiType пустой - не указывай этот параметр. 3. Стиль связи (Flow): edgeStyle=orthogonalEdgeStyle;html=1;shape=archimate3-flow;endArrow=open;endFill=0; 4. Координаты: Убедись, что объекты не перекрывают друг друга (минимальный отступ 50px). 5. Структура: XML должен содержать корневой элемент mxGraphModel с root и mxCell.
Немного обидно, что пока Вы готовили этот цикл статей, вышел 4-й архимейт. Обидно за Вас в первую очередь.
Это разумеется не отменяет реальную пользу материала. Продолжайте пожалуйста цикл. Перенести сам принцип в 4-й - дело техники. Когда появится возможность.
Позволю себе небольшую ремарку. Я, решая схожую задачу, пошёл другим путём.
Для генерации прототипов схем я использую XML: - Archi нативно хранит модель в XML: - DrawIO использует для хранения MxGraphModel, в котором есть полная палитра стиля Archimate
Нейронки прекрасно понимают обе XML-разметки и генерируют достаточно (для прототипа) адекватные схемы.
Из плюсов применения этого подхода - я работаю практически постоянно с confluence и через макрос drawio получаю визуально редактируемую диаграмму.
Всё вышесказанное - не критика, просто поделился своим вариантом подхода. Возможно, пригодится
[2] Фиксация: сотрудник безопасности просит показать пауэрбанк + посадочный, сканирует штрих-код талона (рейс + место)
Требуется: ТСД/сканер + доработка ПО регистрации аэропорта
Время: ~ 30 сек на пассажира с пауэрбанком
[3] Передача данных: после закрытия посадки экипаж запрашивает по номеру рейса список мест с пауэрбанками
Требуется: API между системой аэропорта и бортовой системой авиакомпании
[4] Контроль в салоне: на рулёжке, параллельно с проверкой ремней, бортпроводник точечно просит пассажиров с «отмеченных» мест переложить пауэрбанк в карман кресла. Не досматривая повторно ручную кладь с полки.
Время: ~10 сек на пассажира
Итого:
- Основное время добавляется на этапе досмотра (~30 сек × % пассажиров с пауэрбанками)
- В салоне производится точечный контроль, не массовый досмотр
- Технически решаемо, вопрос в приоритетах и бюджете
Вопрос лишь в том, стоит ли автоматизировать первые три этапа, если самое узкое место - именно человеческий ресурс в салоне?
Не так давно по различным соцсеткам стоял дикий вой и хейт на тему того, что "маркетплейсы ввели платные возвраты".
По сути же, не "ввели", а решили в рамках действующего законодательства не возвращать деньги за доставку товара надлежащего качества. Есть такая норма в ЗоПП реально. Продавец обязан веруть ДС за доставку только при возврате бракованного товара
Боюсь, что прямая тарификация логистических услуг в заказе (как это происходит в "обычных" интернет-магазинах) вызовет серьёзые народные бунты ;) так то они по костам размазаны и явно не заметны.
Да и технически это не очень простая задача. В одном заказе маркетплейса может лежать несколько разных товаров нескольких продавцов несколькими грузоместами. На момент оформления заказа товар ещё не собран, посчитать и добавить в чек доставку чтобы потом её вычесть, можно, но, повторю, не тривиально. В Озон Фреше это сделано, но там просто жесткий тариф только за доставку заказа как таковую
Вопрос практического применения.
Я очень хорошо понимаю говорящих по-английски немцев и итальянцев когда смотрю конференции в оригинале.
С американцами - сложнее, слишком много незнакомых идиом, я часто не уверен, что понял.
Англичан не понимаю вообще. Сразу включаю перевод. Но и встречаются они мне крайне редко, поэтому не страдаю
Поверю :))))
Собственно, об этом и был долгий разговор. Стоит ли учить именно британской версии произношении, если в остальном мире это скорее всего воспринимается именно в "подразумеваемом" смысле.
В итоге сошлись на том, что сын уже достаточно взрослый чтобы объяснить.
Сейчас он произносит "кэнт"
Долгий разговор был с репетитором английского у сына, которая упорно учила его произносить сокращенное "Can not" как "кант".
Да много таких засад в любом языке
В хокку бы это переложить
И можно пилить мемасик топовый :)))
Странный CJM, что завернули на приглашение персонала. Достаточно сигнала + 5-секундной плашки и/или кнопки сброса покупателем.
Но в чужую голову не влезу, не знаю что там "так бизнес хотел".
Я бы, столкнувшись с таким, не поленился написать цветастое дадзыбао куда-нибудь в "обратную связь"
Перечитал статью с калькулятором под рукой.
Камрады видимо сидят на УСН (Доходы минус расходы 15%) и за счёт страховых взносов и возможных льгот имеют ~7%
Ок.
По 176ФЗ камрадам нужно будет платить 5% при обороте >60 млн.
При обороте 2,5 млн с партии НДС 5% = 125т.₽ сверху, которые либо убьют заявленную маржу, либо придётся повышать цену и получать снижения спроса.
На этот оборот они по цифрам (мы же им верим?) вот-вот выйдут, то есть вопрос стоит остро.
И тут возникает момент, который камрады видимо постеснялись упомянуть :)) Им неоткуда платить этот НДС:
- при
контрабандекарго-ввозе нет входного НДС (нет ГТД), а значит нет права на вычет, то есть те самые 5% платить нужно, а вычесть нечего.- НДС платится с отгрузок, а деньги от маркетплейса приходят с задержкой 7–14 дней. Нужен оборотный капитал, которого нет. Типовой кассовый разрыв.
Вариантов у них особо нет, либо дробить бизнес (ещё большие риски, которых и так хватает. Там в статье заявлена ещё покупка отзывов в явном виде, а это ещё пара статей, если по-серьёзному домотаться), либо уходить на ОСНО в белую, а с их маржой ~4 это глубокий минус.
Чёт есть ощущение, что тут не только маркетплейсы виноваты ))))))
Да, разумеется.
И 1-я линия ТП на трубе с персоналом магазина скорее всего не дойдут до этого.
Но инциденты с кассами - это по дефолту высокий приоритет, а значит до 3-й линии инцидент долетит очень быстро. И там пришлют штрихкоды, сбросят и настроят заново.
Ну ок. За 10 минут я конечно слишком оптимистично заявил :)))))
Автору вопрос.
Вы уверены, что подробное описание карго-ввоза удовлетворяет тематике хаба "бизнес-модели"?
Чего конечно не встретишь на Хабре ...
Конкретно у этих товарищей суммы смешные (если там реально 300к₽ в месяц) и с ними даже по 16.1 .. 16.3 КоАП и 122НК связываться вряди кто будет.
Но если Ваш шедевр прочитают другие люди, примут как норму, решат воспользоваться советом и влетят уже на 194УК ?
Вам людей то не жалко за плюсики на хабре?
Про ТСД.
Да, привычка - дело реально серьёзное. Просто интересно стало. Я бы покурил с заказчиком этот вопрос, попадись мне такая задача. Дело тут даже не в мобильности рабочего места. На ТСД сам UI нативнее для таких задач.
Там другие минусы типа интеграции с Эской в недрах склада, глухие зоны wifi, обрывы коннекта и прочие неприятности
Про сканера - да, разумеется. Подавляющее большинство моделей настраиваются служебными штрихкодами.
Насчёт вектора атаки - я реально в ступоре. Можете придумать кейс? Ну допустим Вы на кассе самообслуживания в условной Пятерочке отсканировали 3 штрихкода (кстати, для этого модель их сканера нужно знать). Режим программирования - запрет чтения датаматрикс - сохранение настроек. Ну перестала касса на некоторое время пробивать кефир и прочий Честный знак. Пока поддержка руками директора магазина не сбросила сканер в дефолт и не вернула настройки. Дел на 10 минут.
Ну а дальше идёт вызов наряда, съём данных с камер и привет минимум административка за хулиганство. Причём не отвертишься никак. Штрихкоды специальные, умысел докажет любой первокурсник с юрфака.
Если кто-то покажет сканеру любой штрихкод из методички по программированию (а не только коды для перевода в режим эмуляции клавиатуры и обратно в Com), то хорошо проинструктированный суровый начальник смены оторвёт ему руки.
Так - работает. Многократно проверено.
В сторону ТСД вообще не смотрели? Любопытно зачем оставили моноблоки, если по-любому софт допилиливали?
10000 / 30 дней / 12 рабочих часов - это примерно 1 выдача в 2 минуты. Конвейер.
Я не буду спорить с Вашей математикой, своей по-любому нет. Но у меня паззл не сошёлся.
В целом логика, которую Вы привели абсолютно рабочая, розничные продуктовые сети тоже от оборота на количество жителей вокруг точки раньше считали. Но цифры мне кажутся странными
У Вас случаем нет источника этой цифры (1500..2000)?
Это не троллинг, реально интересно.
Если под рукой нет и/или долго искать - не расстроюсь.
Если совсем коротко, то да. При превышении лимита мест хранения и скорости выдачи, ПВЗ просто нельзя выбрать для доставки. Если интересно, можно помониторить вал таких отключений при приближении крупного праздника типа 8 марта.
По отношению к покупателям тут с одной стороны, да. Наличие лимита - это неудобно. С другой стороны
- в ПВЗ в основном используется ячеечная система хранения, которая обеспечивает высокую скорость и точность выдачи. Сотрудник не ковырятся полчаса в мешках в поисках заказа. Это для покупателя положительно. Зашел-забрал
- в ПВЗ ограничено количество сотрудников. При условной норме обслуживания 3 минуты на заказ, больше 20 заказов на час на точку распределять нельзя - будет очередь и беготня
Я имею в виду, что "лимиты" - обычное ограничение процесса. Но могут использоваться не только по прямому назначению :)
В данном случае требования к методу обработки уже детерменированы, не меняются от запуска к запуску и их формулирование не дается на откуп модели в инференсе.
То, что промпт написан с применением LLM, в данном случае не играет сильной роли. Это малая автоматизация, почему бы и нет, если результат проверен. Важнее то, что на входе есть стабильный фиксированный перечень требований.
Разумеется, это не даёт 101% гарантии, но минимум иллюзия управляемости уже есть
Есть ощущение, что там расстояния не позволят использовать дроны без станций подзарядки по дороге.
Чисто ИМХО, данных на руках нет
Вдогонку к предыдущему, не успел за время редактирования.
Нашёл пример для DrawIO. Загнал под спойлер
Пример
Кусок промпта:
Немного обидно, что пока Вы готовили этот цикл статей, вышел 4-й архимейт. Обидно за Вас в первую очередь.
Это разумеется не отменяет реальную пользу материала. Продолжайте пожалуйста цикл. Перенести сам принцип в 4-й - дело техники. Когда появится возможность.
Позволю себе небольшую ремарку. Я, решая схожую задачу, пошёл другим путём.
Для генерации прототипов схем я использую XML:
- Archi нативно хранит модель в XML:
- DrawIO использует для хранения MxGraphModel, в котором есть полная палитра стиля Archimate
Нейронки прекрасно понимают обе XML-разметки и генерируют достаточно (для прототипа) адекватные схемы.
Из плюсов применения этого подхода - я работаю практически постоянно с confluence и через макрос drawio получаю визуально редактируемую диаграмму.
Всё вышесказанное - не критика, просто поделился своим вариантом подхода. Возможно, пригодится
Я вероятно перегрузил ответ образами :)
Давайте попробую показать ту же логику, но просто кейсом с точки зрения человека, который проектирует схожие процессы.
Предпосылки:
- Досмотр ручной клади проходят 100% пассажиров перед входом в «стерильную зону»
- Пауэрбанк технически виден на рентгене
- Столы дополнительного досмотра (где просят включить телефоны и ноутбуки) уже существуют
Как это могло бы работать:
[1] Досмотр: сотрудник видит пауэрбанк на рентгене -> направляет пассажира на доп. досмотр
Требуется: краткое дообучение операторов (распознавание батарей)
[2] Фиксация: сотрудник безопасности просит показать пауэрбанк + посадочный, сканирует штрих-код талона (рейс + место)
Требуется: ТСД/сканер + доработка ПО регистрации аэропорта
Время: ~ 30 сек на пассажира с пауэрбанком
[3] Передача данных: после закрытия посадки экипаж запрашивает по номеру рейса список мест с пауэрбанками
Требуется: API между системой аэропорта и бортовой системой авиакомпании
[4] Контроль в салоне: на рулёжке, параллельно с проверкой ремней, бортпроводник точечно просит пассажиров с «отмеченных» мест переложить пауэрбанк в карман кресла. Не досматривая повторно ручную кладь с полки.
Время: ~10 сек на пассажира
Итого:
- Основное время добавляется на этапе досмотра (~30 сек × % пассажиров с пауэрбанками)
- В салоне производится точечный контроль, не массовый досмотр
- Технически решаемо, вопрос в приоритетах и бюджете
Вопрос лишь в том, стоит ли автоматизировать первые три этапа, если самое узкое место - именно человеческий ресурс в салоне?
Не так давно по различным соцсеткам стоял дикий вой и хейт на тему того, что "маркетплейсы ввели платные возвраты".
По сути же, не "ввели", а решили в рамках действующего законодательства не возвращать деньги за доставку товара надлежащего качества. Есть такая норма в ЗоПП реально. Продавец обязан веруть ДС за доставку только при возврате бракованного товара
Боюсь, что прямая тарификация логистических услуг в заказе (как это происходит в "обычных" интернет-магазинах) вызовет серьёзые народные бунты ;) так то они по костам размазаны и явно не заметны.
Да и технически это не очень простая задача. В одном заказе маркетплейса может лежать несколько разных товаров нескольких продавцов несколькими грузоместами. На момент оформления заказа товар ещё не собран, посчитать и добавить в чек доставку чтобы потом её вычесть, можно, но, повторю, не тривиально. В Озон Фреше это сделано, но там просто жесткий тариф только за доставку заказа как таковую