Странно, я всегда считал что когда подобный процесс (даже безо всякого ИИ) пошел не по плану, это штатная ситуация. Исправляется откатом на состояние до начала операции. Очевидно, что как только стало ясно что дело идет не по плану (удалилось (или даже могло удалиться) хотя бы одно письмо), никакой срочности в kill / stop уже нет - надо будет восстанавливать данные.
Конечную продукцию можно исключить из-за маркировки. Остается оптовая продажа, где продукция она используется на следующей стадии как сырье (ткань например). Покупатель перед заказом попросит на товар документацию, сертификаты, прочие документы. В сертификате указан конкретный производитель. Если продукция по ТУ то оно на конкретного производителя. И так во всем. Соответственно отгружать надо будет продукцию того же производителя. Не говоря уже о качестве самой продукции (если это, конечно, реальное производство, а не наклеивание шильдиков на китайский товар). Оно различается (плотность, толщина и проч). А это сырье для следующей стадии производства. Нельзя просто так поменять качество сырья (поставщика) без перенастройки производственных линий. Поэтому не особо реальная ситуация.
Почему у вас при все плюсах решения 1 выбрано 2 я не понял. В Файле по ссылке есть утверждение про "доработка реализована через расширение. Типовое обновление не приводит к конфликтам". Непонятно на чем основано. Код же меняется. Всегда могут быть изменения в конфигурации поставщика, влияющие на доработки. Не понял почему в варианте 1 надо дорабатывать код для новых видов поступлений - привязку в типам документов может вынести в отдельный справочник.
Можно вообще не менять код типовой конфигурации. Уже после штатного формирования проводок отдельной обработкой менял счет учета. Именно в плане максимально простой поддержки, совместимости с обновлениям. Потому что задача намного сложнее, чем Вы пишете. Кроме Приобретения и Выпуска партии могут создаваться возвратами, пересортицами, излишкам. У Вас рассмотрено только одно юр. лицо, а может появиться второе. Тогда добавятся еще и передачи товаров между организациями. В сочетании с возврвтами это может приводить к потере исходных партий.
Постановку задачи, видимо, нейросеть писала. Во-первых, упомянутые в статье товары легкой промышленности в РФ уже несколько лет под маркировкой ("Честный знак"). Это поэкземплярный учет. Во-вторых даже если продукция каким-то образом и не под маркировкой, то у нее будет сертификат или хотя бы декларация соответствия. Где будет указан производитель. Он же должен быть указан на упаковках для розничной продажи. Какой-нибудь частник на рынке может продавать просто "гвозди". Но на предприятии с ERP никакого смешения не будет. Не говоря уже о таких вещах, как необходимость контроля качества, отслеживания бракованных партий и т.п.
Видимо на основании лога. Представьте, что покупателю в магазине дают купон на скидку, в нем написано: скидка 30%. А когда этот купон покупатель предъявляет на кассе, говорят что "у нас нет такого в системе" и в скидке отказывают. При том что купон оригинальный (не подделка). Конечно покупатель пойдет в суд.
Скидка может выдаваться случайным образом (типа лотереи), в т.ч. скриптом. Также с непредсказуемым результатом. И ничего тут пока не выяснилось. Я так понял, что магазин вернул деньги. Но он мог сделать это и против воли покупателя. Не говорится ничего о том, что покупатель отказался от намерения обратиться в суд.
Как в Великобритании, не знаю, но в РФ участником гражданского ИИ оборота не является. Только юридические и физические лица. ИИ ничем принципиально не отличается от любой другой программы, рассчитывающей цены / скидки. Например, скрипта на сайте. Нарушение со стороны клиента будет если клиент выторговывая скидку сообщил заведомо недостоверную информацию - например обещал в будущем сделать много заказов, которые он заведомо сделать не мог и т.п. Если просто уговорил, в итоге магазин сделал оферту (предложил купить товар по такой-то цене), а покупатель - акцептовал ее (оплатил товар) - то нет оснований не исполнять договор.
На просьбу предоставить платежный документ (кроме случаев, явно предусмотренных законом) гражданин имеет полное право дать отказ. Такая просьба - демонстрация неуважения к клиентам. Потому что платежный документ через банковскую систему при зачислении денег передается получателю платежа (в электронном виде). Точно такой же, у плательщика - списание со счета, у получателя - зачисление на счет. Идите в свою бухгалтерию и ищите там.
"Оплатил от своего имени" уже года 3 как не работает (ну если только в "черной" бухгалтерии). Если сотрудник действует от имени юр. лица он обязан сообщить об этом контрагенту и контрагент в кассовом чеке должен указать ИНН и название юр. лица покупателя. А если нужен зачет НДС - еще и счет-фактуру выписать. Иначе юр. лицо не сможет принять расходы по авансовому отчету.
Данные, скан, паспорта не подтверждают вообще ничего. Паспорт это не вексель на предъявителя. Паспорт подтверждает личность только при предъявлении владельцем.
Банковские документы подтверждают что платило конкретное физ. лицо, и то при условии что это обычное платежное поручение со счета физ. лица, где указан номер счета и плательщик полностью. А не какой-нибудь чек из терминала, где написано что оплата по договору за такого-то (по факту любой может написать за любого)
Наличие платежных документов в письме с почты не подтверждает, что данная почта принадлежит указанному в документах лицу. Вообще никак. Поэтому зная физ. лицо самый простой законный способ передать управление именно ему - сбросить пароль и отправить по адресу регистрации по почте заказным / ценным письмом.
Более современный способ - попросить прислать заявление, подписанное усиленной квалифицированной электронной подписью, в нем физ. лицо указывает почту, куда прислать пароль. Пароль еще и зашифровать сертфиикатом этого физ. лица Если у физ. лица УКЭП нет - идет к нотариусу, пишет заявление на бумаге, нотариус заверяет подпись, сканирует, подписывает скан своей УКЭП (нотариуса), выдает файл со сканом и файл с подписью заявителю, тот отправляет Вам.
Оно и штатно делается без потери контекста (перезапуска, открытия форм и проч). Код метода копируется во внешнюю обработку, в самом методе делается создание этой обработки и вызов метода из модуля обработки (формы обработки, если это клиентскиий код). Отладка при этом работает. И можно добавлять методы (которые будут вызываться из уже вынесенных в обработку). Благо при отладке какого-то процесса набор методов которые надо менять, небольшой и их можно вынести заранее. Но тут, конечно, более автоматизированно.
В статье написано "Нарушение авторских прав на ПО при тестировании защищенности. Перед проведением пентестов российские ИБ-специалисты обязаны получить разрешение от разработчиков ПО, чьи продукты используются в тестируемой системе" Можно узнать, на чем основано это утверждение ? В материале по ссылке есть указания на конкретные судебные дела, я прочитал их. Все эти дела касаются обычных случаев использования ПО без лицензии. Ни о каких тестах защищенности в этих судебных делах не говорится. Случаев же, когда организация, купившая ПО, проводила тесты защищенности и за это правообладатель с нее за это что-то взыскал, я не увидел.
Тут речь идет о выполнении нормативно-правового акта. Выполнtтся согласно изложенным в нем требованиям, а не как кому-то удобно. Подозреваю, что в данном НПА конкретно не написаны критерии, по которым надо отключать. Каждый оператор делает как понимает. К тому же оборудование может быть разное, ПО разное, результат тоже разный. Даже в правовых нормах, действующих десятки лет, находятся неоднозначности и суды принимают противоположные решения. А тут норма с историей меньше месяца. Разная реализация может быть запросто. Не удивлюсь, если в каких-то других случах будет наоборот - сим-карта от МТС продолжать будет работать там где другие отключатся.
Использование, регистрация сим карты это довольно общие условия. Я не знаю работу сотовой связи подробно, но подозреваю, что "регистрацию" БС отслеживает не на 100%. То есть иногда звонишь абоненту и сразу получаешь ответ, что он недоступен. А иногда этот ответ получаешь с задержкой в несколько десятков секунд. Как будто БС считает что сим-карта в сети и пытается до нее дозвониться, а реально она уже не в сети. Вот оператор и подстраховался на такие случаи. Я допускаю, что для определения "использования" могут применяться только определенные виды коммуникаций телефона (модема) с базовой станцией. И телефон, постоянно находящийся в режиме ожидания, особенно если он еще и рядом с одной и той же БС, может таких коммуникаций не осуществлять. А всякие "умные" устройства, понимая что передавать нечего, вообще могут выключать модем для экономии электроэнергии. Поэтому если реально критичные устройства затронуты, логично вместе с тех. специалистами оператора работу каждого устройства разбирать подробно, чтобы не попадать на "неиспользование".
Мне Сбербанк один раз номер телефона, привязанный к Сбербанк-Онлайн, по "неиспользованию" поменял. Захожу в СБОЛ, код в СМС не приходит. Думаю что-то не работает, заплатил другим способом. Через некоторое время обнаружил эти СМС на другом телефоне, который был давно отключен от СБОЛ. (Документы о смене номера в банке сохранились). И это еще хорошо я только от СБОЛ отключил, но сам номер оставался моим. Написал в техподдержку, ответили, что "СМС-банк был отключён от номера +7 *, так как в течение полугода не было входящих и исходящих СМС.". К письму прилагался список всех СМС, которые мне отправлял банк (одноразовые пароли, уведомления о входе в СБОЛ и т.п.). При этом большинство СМС имело признак что они доставлены (к тому же раз я ввел код, значит реально получил СМС). То есть "не было СМС" провергалось этим же письмом. Я написал повторно, мне опять ответили по сути тоже самое (отключение по неиспользованию). Но после третьего обращения мне ответили по сути:
"СМС – банк был отключён от номера телефона +7 * по причине неактивности номера телефона. В ходе проверки установлено, что с октября 2020г по январь 2021г отсутствовали СМС – сообщения в рамках услуги СМС - банк (по проведенным операциям по карте). СМС - сообщения о входе в СберБанк Онлайн, а также коды для подтверждения платежей в СберБанк Онлайн направлялись вне рамок услуги СМС-банк. До отключения услуги банком направлялись проверочные СМС-сообщения, например:
19.12.2020 10:03 (МСК) «Уважаемый клиент! Вам доступна услуга Мобильный банк. Для получения информации отправьте на номер 900 SMS: СПРАВКА»;
02.01.2021 10:01 (МСК) «Уважаемый клиент! Вам доступна услуга Мобильный банк. Для получения информации отправьте на номер 900 SMS: СПРАВКА».
Так как указанные СМС – сообщения не были доставлены на номер +7 * по причине «абонент временно недоступен», а также из-за ошибки оператора сотовой связи, Вами не были направлены ответы на запросы, и услуга была отключена. Отчёт о направленных СМС на номер +7 * прилагается.
По вопросу непоступления СМС рекомендуем обратиться к оператору сотовой связи для уточнения причины.
Банком проведены технические корректировки. На 01.06.2021 СМС-сообщения о входе в СберБанк Онлайн, а также коды для подтверждения платежей в СберБанк Онлайн направляются с номера 900 в рамках услуги СМС-банк. В дальнейшем отключение услуги СМС – банк по причине неактивности номера проводиться не будет.
Приносим извинения за неудобства."
По вопросу "почему вместо блокировки текущего номера, произошло его отключение и подключение предыдущего номера" (это они признали), у меня уже не было времени продолжать переписку и добиваться конкретной причины.
Номер обращения 210315-0828-472000 от 15.03.2021 если что.
Вот и у оператора в Вашем случае скорее всего что-то похожее.
Пришел ответ от службы поддержки Яндекс 360 (вопрос по отображению шифрования в Яндекс почте. См комментарий чуть выше).
[Ticket#25081909192776468] ssl-шифрование в письме Обозначение шифрования в нашем интерфейсе указывает на то, что письмо шло по защищённому каналу внутри инфраструктуры Яндекса. При этом оно не означает, что письмо было отправлено с SSL-шифрованием.
Продавцу на недостаток устройства. Покупая какой-то электроприбор, потребитель не должены проверять, сделано ли в нем заземление, установлен ли предохранитель, правильно ? Есть стандарт в котором все это описано. Что для какого прибора должно быть. Раз прибор продается в магазине на территории РФ, этот стандарт должен быть выполнен. Если выявилось несоответствие стандарту, у покупателя есть право обратиться к продавцу и потребовать устранения недостатка. Здесь тоже самое.
Зря Вы 1С выбрали в статье в качестве среды для написания запросов к LLM. Это приводит к тому, что смотришь на результат с точки зрения применения 1С, а тут нужно чтобы бы просто работало.
Может быть с точки зрения ИТ консультанта, продвигающего LLM тут все хорошо, типа смотрите, написал одно предлжение и все сделано. Но с мой точки зрения написанное работать не будет, и получается что основная задача не выполнена.
Проблемы (писал как я вижу выполнение этого кода, возможно в чем-то ошибся):
Себестоимость рассчитана делением суммы закупки на количество. Это приведет к ошибкам - будут не сходиться копейки. Пример: Поступили 3 товара на сумму 100 руб. Для равномерного списания себестоимости необходимо по каждой входящей партии учитывать остаток не только количества, но и суммы. Расчет себестоимости проводить на момент списания. (Решение через систему линейных уравнений, применяемое в ERP, я тут не рассматриваю).
Не учтен "момент времени". Данные отсортированы просто по дате. Но в одну дату может быть несколько документов. Для того, чтобы гарантировать их порядок в пределах даты, необходимо добавить еще одну колонку (например порядковый номер) и применять сортировку сначала по дате, затем по порядковому номеру.
При списании не учитывается дата поступления. То есть она без ограничения списывает партии из будущих поставок, а так не должно быть. Поступление должно быть не позже этой же даты или конца месяца.
Нет поддержки возвратов. То есть записей с отрицательным количеством.
Мелочи типа правильно добавить округления, try без обработки except, то что нельзя сравнивать float равно 0 я даже не рассматриваю.
Реально можно взять готовый пример импорта данных для pandas, изменить в нем названия и типы колонок и получить во входных таблицах тоже самое. С примерно теми же затратами времени. А что касается основного алгоритма то проще писать его самому чем пытаться адаптировать то что здесь написано. Потому что хорошо, когда есть явная ошибка. А при исправлении чужого кода легко получить мелкую неявную ошибку. Которая допущена в январе, но не проявится сразу, а проявится в декабре. И придется объяснять руководству, что нам надо открывать период и перезакрывать все месяца с начала года, с пересдачей отчетности.
Для управления критичными вещами надо выделять отдельное устройство (компьютер, телефон). На котором без необходимости не производится никаких изменений в софте, настройках и проч. Сам софт стоит минимально необходимый и ничего лишнего.
Пожилому человеку (дееспособному) сложно разбираться в условиях договоров, личных кабинетах и проч. Все этим МБит/с, 5G и пр. ему ничего не говорят. История которая затронула моих родственников. Оператор проводной телефонной сети (он же и интернет) обзванивал людей и предлагал перейти на тариф с более быстрым интернетом. Скорее всего честно называл условия (что повысится абон плата). Пожилые люди не особо понимали что, тут происходит, но основном соглашались. Их переводили на тариф 500 МБит/с (+200 р к абон плате). Хотя если оператор делал хотя бы минимальный анализ трафика, такого предложения никогда не поступило бы. В моем случае реальная скорость на предоставленном оператором же роутере с WiFi типа N с учетом нахождения клиентского устройства за бетонной стеной была 20Мбит/с максимум. И такая конфигурация была несколько лет. Тариф переключили назад на минимально возможной, по поводу уже списанных денег претензию родственник писать не стал. После того как это выявилось, родственник пообщался с соседями и оказалось что аналогичное происходило у многих пожилых людей. То же самое касается и выдачи телефонов несовершеннолетним детям. По всем технически сложным услугам такие люди должны иметь возможность быть чисто пользователями и не более того. А не стороной договора. Не должно быть возможности войти в личный кабинет оператора по паролю через СМС на такой телефон и т.п. Сейчас это возможно по сути только на корпоративном тарифе.
К ООО "Яндекс" надо бы добавить ИНН или ОГРН чтобы организация была четко определена. Потому что с таким названием организаций несколько. Можете зайти на https://egrul.nalog.ru и убедиться.
Странно, я всегда считал что когда подобный процесс (даже безо всякого ИИ) пошел не по плану, это штатная ситуация. Исправляется откатом на состояние до начала операции. Очевидно, что как только стало ясно что дело идет не по плану (удалилось (или даже могло удалиться) хотя бы одно письмо), никакой срочности в kill / stop уже нет - надо будет восстанавливать данные.
Конечную продукцию можно исключить из-за маркировки. Остается оптовая продажа, где продукция она используется на следующей стадии как сырье (ткань например). Покупатель перед заказом попросит на товар документацию, сертификаты, прочие документы. В сертификате указан конкретный производитель. Если продукция по ТУ то оно на конкретного производителя. И так во всем. Соответственно отгружать надо будет продукцию того же производителя. Не говоря уже о качестве самой продукции (если это, конечно, реальное производство, а не наклеивание шильдиков на китайский товар). Оно различается (плотность, толщина и проч). А это сырье для следующей стадии производства. Нельзя просто так поменять качество сырья (поставщика) без перенастройки производственных линий. Поэтому не особо реальная ситуация.
Почему у вас при все плюсах решения 1 выбрано 2 я не понял. В Файле по ссылке есть утверждение про "доработка реализована через расширение. Типовое обновление не приводит к конфликтам". Непонятно на чем основано. Код же меняется. Всегда могут быть изменения в конфигурации поставщика, влияющие на доработки. Не понял почему в варианте 1 надо дорабатывать код для новых видов поступлений - привязку в типам документов может вынести в отдельный справочник.
Можно вообще не менять код типовой конфигурации. Уже после штатного формирования проводок отдельной обработкой менял счет учета. Именно в плане максимально простой поддержки, совместимости с обновлениям. Потому что задача намного сложнее, чем Вы пишете. Кроме Приобретения и Выпуска партии могут создаваться возвратами, пересортицами, излишкам. У Вас рассмотрено только одно юр. лицо, а может появиться второе. Тогда добавятся еще и передачи товаров между организациями. В сочетании с возврвтами это может приводить к потере исходных партий.
Постановку задачи, видимо, нейросеть писала.
Во-первых, упомянутые в статье товары легкой промышленности в РФ уже несколько лет под маркировкой ("Честный знак"). Это поэкземплярный учет.
Во-вторых даже если продукция каким-то образом и не под маркировкой, то у нее будет сертификат или хотя бы декларация соответствия. Где будет указан производитель. Он же должен быть указан на упаковках для розничной продажи. Какой-нибудь частник на рынке может продавать просто "гвозди". Но на предприятии с ERP никакого смешения не будет. Не говоря уже о таких вещах, как необходимость контроля качества, отслеживания бракованных партий и т.п.
Видимо на основании лога. Представьте, что покупателю в магазине дают купон на скидку, в нем написано: скидка 30%. А когда этот купон покупатель предъявляет на кассе, говорят что "у нас нет такого в системе" и в скидке отказывают. При том что купон оригинальный (не подделка). Конечно покупатель пойдет в суд.
Скидка может выдаваться случайным образом (типа лотереи), в т.ч. скриптом. Также с непредсказуемым результатом. И ничего тут пока не выяснилось. Я так понял, что магазин вернул деньги. Но он мог сделать это и против воли покупателя. Не говорится ничего о том, что покупатель отказался от намерения обратиться в суд.
Как в Великобритании, не знаю, но в РФ участником гражданского ИИ оборота не является. Только юридические и физические лица. ИИ ничем принципиально не отличается от любой другой программы, рассчитывающей цены / скидки. Например, скрипта на сайте. Нарушение со стороны клиента будет если клиент выторговывая скидку сообщил заведомо недостоверную информацию - например обещал в будущем сделать много заказов, которые он заведомо сделать не мог и т.п. Если просто уговорил, в итоге магазин сделал оферту (предложил купить товар по такой-то цене), а покупатель - акцептовал ее (оплатил товар) - то нет оснований не исполнять договор.
На просьбу предоставить платежный документ (кроме случаев, явно предусмотренных законом) гражданин имеет полное право дать отказ. Такая просьба - демонстрация неуважения к клиентам. Потому что платежный документ через банковскую систему при зачислении денег передается получателю платежа (в электронном виде). Точно такой же, у плательщика - списание со счета, у получателя - зачисление на счет. Идите в свою бухгалтерию и ищите там.
"Оплатил от своего имени" уже года 3 как не работает (ну если только в "черной" бухгалтерии). Если сотрудник действует от имени юр. лица он обязан сообщить об этом контрагенту и контрагент в кассовом чеке должен указать ИНН и название юр. лица покупателя. А если нужен зачет НДС - еще и счет-фактуру выписать. Иначе юр. лицо не сможет принять расходы по авансовому отчету.
Данные, скан, паспорта не подтверждают вообще ничего. Паспорт это не вексель на предъявителя. Паспорт подтверждает личность только при предъявлении владельцем.
Банковские документы подтверждают что платило конкретное физ. лицо, и то при условии что это обычное платежное поручение со счета физ. лица, где указан номер счета и плательщик полностью. А не какой-нибудь чек из терминала, где написано что оплата по договору за такого-то (по факту любой может написать за любого)
Наличие платежных документов в письме с почты не подтверждает, что данная почта принадлежит указанному в документах лицу. Вообще никак.
Поэтому зная физ. лицо самый простой законный способ передать управление именно ему - сбросить пароль и отправить по адресу регистрации по почте заказным / ценным письмом.
Более современный способ - попросить прислать заявление, подписанное усиленной квалифицированной электронной подписью, в нем физ. лицо указывает почту, куда прислать пароль. Пароль еще и зашифровать сертфиикатом этого физ. лица
Если у физ. лица УКЭП нет - идет к нотариусу, пишет заявление на бумаге, нотариус заверяет подпись, сканирует, подписывает скан своей УКЭП (нотариуса), выдает файл со сканом и файл с подписью заявителю, тот отправляет Вам.
Оно и штатно делается без потери контекста (перезапуска, открытия форм и проч). Код метода копируется во внешнюю обработку, в самом методе делается создание этой обработки и вызов метода из модуля обработки (формы обработки, если это клиентскиий код). Отладка при этом работает. И можно добавлять методы (которые будут вызываться из уже вынесенных в обработку). Благо при отладке какого-то процесса набор методов которые надо менять, небольшой и их можно вынести заранее. Но тут, конечно, более автоматизированно.
В статье написано "Нарушение авторских прав на ПО при тестировании защищенности. Перед проведением пентестов российские ИБ-специалисты обязаны получить разрешение от разработчиков ПО, чьи продукты используются в тестируемой системе"
Можно узнать, на чем основано это утверждение ?
В материале по ссылке есть указания на конкретные судебные дела, я прочитал их. Все эти дела касаются обычных случаев использования ПО без лицензии. Ни о каких тестах защищенности в этих судебных делах не говорится.
Случаев же, когда организация, купившая ПО, проводила тесты защищенности и за это правообладатель с нее за это что-то взыскал, я не увидел.
Тут речь идет о выполнении нормативно-правового акта. Выполнtтся согласно изложенным в нем требованиям, а не как кому-то удобно. Подозреваю, что в данном НПА конкретно не написаны критерии, по которым надо отключать. Каждый оператор делает как понимает. К тому же оборудование может быть разное, ПО разное, результат тоже разный. Даже в правовых нормах, действующих десятки лет, находятся неоднозначности и суды принимают противоположные решения. А тут норма с историей меньше месяца.
Разная реализация может быть запросто.
Не удивлюсь, если в каких-то других случах будет наоборот - сим-карта от МТС продолжать будет работать там где другие отключатся.
Использование, регистрация сим карты это довольно общие условия.
Я не знаю работу сотовой связи подробно, но подозреваю, что "регистрацию" БС отслеживает не на 100%. То есть иногда звонишь абоненту и сразу получаешь ответ, что он недоступен. А иногда этот ответ получаешь с задержкой в несколько десятков секунд. Как будто БС считает что сим-карта в сети и пытается до нее дозвониться, а реально она уже не в сети. Вот оператор и подстраховался на такие случаи.
Я допускаю, что для определения "использования" могут применяться только определенные виды коммуникаций телефона (модема) с базовой станцией. И телефон, постоянно находящийся в режиме ожидания, особенно если он еще и рядом с одной и той же БС, может таких коммуникаций не осуществлять. А всякие "умные" устройства, понимая что передавать нечего, вообще могут выключать модем для экономии электроэнергии.
Поэтому если реально критичные устройства затронуты, логично вместе с тех. специалистами оператора работу каждого устройства разбирать подробно, чтобы не попадать на "неиспользование".
Мне Сбербанк один раз номер телефона, привязанный к Сбербанк-Онлайн, по "неиспользованию" поменял. Захожу в СБОЛ, код в СМС не приходит. Думаю что-то не работает, заплатил другим способом. Через некоторое время обнаружил эти СМС на другом телефоне, который был давно отключен от СБОЛ. (Документы о смене номера в банке сохранились). И это еще хорошо я только от СБОЛ отключил, но сам номер оставался моим.
Написал в техподдержку, ответили, что "СМС-банк был отключён от номера +7 *, так как в течение полугода не было входящих и исходящих СМС.". К письму прилагался список всех СМС, которые мне отправлял банк (одноразовые пароли, уведомления о входе в СБОЛ и т.п.). При этом большинство СМС имело признак что они доставлены (к тому же раз я ввел код, значит реально получил СМС). То есть "не было СМС" провергалось этим же письмом.
Я написал повторно, мне опять ответили по сути тоже самое (отключение по неиспользованию). Но после третьего обращения мне ответили по сути:
"СМС – банк был отключён от номера телефона +7 * по причине неактивности номера телефона.
В ходе проверки установлено, что с октября 2020г по январь 2021г отсутствовали СМС – сообщения в рамках услуги СМС - банк (по проведенным операциям по карте). СМС - сообщения о входе в СберБанк Онлайн, а также коды для подтверждения платежей в СберБанк Онлайн направлялись вне рамок услуги СМС-банк.
До отключения услуги банком направлялись проверочные СМС-сообщения, например:
19.12.2020 10:03 (МСК) «Уважаемый клиент! Вам доступна услуга Мобильный банк. Для получения информации отправьте на номер 900 SMS: СПРАВКА»;
02.01.2021 10:01 (МСК) «Уважаемый клиент! Вам доступна услуга Мобильный банк. Для получения информации отправьте на номер 900 SMS: СПРАВКА».
Так как указанные СМС – сообщения не были доставлены на номер +7 * по причине «абонент временно недоступен», а также из-за ошибки оператора сотовой связи, Вами не были направлены ответы на запросы, и услуга была отключена.
Отчёт о направленных СМС на номер +7 * прилагается.
По вопросу непоступления СМС рекомендуем обратиться к оператору сотовой связи для уточнения причины.
Банком проведены технические корректировки. На 01.06.2021 СМС-сообщения о входе в СберБанк Онлайн, а также коды для подтверждения платежей в СберБанк Онлайн направляются с номера 900 в рамках услуги СМС-банк. В дальнейшем отключение услуги СМС – банк по причине неактивности номера проводиться не будет.
Приносим извинения за неудобства."
По вопросу "почему вместо блокировки текущего номера, произошло его отключение и подключение предыдущего номера" (это они признали), у меня уже не было времени продолжать переписку и добиваться конкретной причины.
Номер обращения 210315-0828-472000 от 15.03.2021 если что.
Вот и у оператора в Вашем случае скорее всего что-то похожее.
Пришел ответ от службы поддержки Яндекс 360 (вопрос по отображению шифрования в Яндекс почте. См комментарий чуть выше).
[Ticket#25081909192776468] ssl-шифрование в письме
Обозначение шифрования в нашем интерфейсе указывает на то, что письмо шло по защищённому каналу внутри инфраструктуры Яндекса.
При этом оно не означает, что письмо было отправлено с SSL-шифрованием.
Продавцу на недостаток устройства.
Покупая какой-то электроприбор, потребитель не должены проверять, сделано ли в нем заземление, установлен ли предохранитель, правильно ? Есть стандарт в котором все это описано. Что для какого прибора должно быть. Раз прибор продается в магазине на территории РФ, этот стандарт должен быть выполнен. Если выявилось несоответствие стандарту, у покупателя есть право обратиться к продавцу и потребовать устранения недостатка.
Здесь тоже самое.
Зря Вы 1С выбрали в статье в качестве среды для написания запросов к LLM. Это приводит к тому, что смотришь на результат с точки зрения применения 1С, а тут нужно чтобы бы просто работало.
Может быть с точки зрения ИТ консультанта, продвигающего LLM тут все хорошо, типа смотрите, написал одно предлжение и все сделано. Но с мой точки зрения написанное работать не будет, и получается что основная задача не выполнена.
Проблемы (писал как я вижу выполнение этого кода, возможно в чем-то ошибся):
Себестоимость рассчитана делением суммы закупки на количество. Это приведет к ошибкам - будут не сходиться копейки. Пример: Поступили 3 товара на сумму 100 руб. Для равномерного списания себестоимости необходимо по каждой входящей партии учитывать остаток не только количества, но и суммы. Расчет себестоимости проводить на момент списания. (Решение через систему линейных уравнений, применяемое в ERP, я тут не рассматриваю).
Не учтен "момент времени". Данные отсортированы просто по дате. Но в одну дату может быть несколько документов. Для того, чтобы гарантировать их порядок в пределах даты, необходимо добавить еще одну колонку (например порядковый номер) и применять сортировку сначала по дате, затем по порядковому номеру.
При списании не учитывается дата поступления. То есть она без ограничения списывает партии из будущих поставок, а так не должно быть. Поступление должно быть не позже этой же даты или конца месяца.
Нет поддержки возвратов. То есть записей с отрицательным количеством.
Мелочи типа правильно добавить округления, try без обработки except, то что нельзя сравнивать float равно 0 я даже не рассматриваю.
Реально можно взять готовый пример импорта данных для pandas, изменить в нем названия и типы колонок и получить во входных таблицах тоже самое. С примерно теми же затратами времени.
А что касается основного алгоритма то проще писать его самому чем пытаться адаптировать то что здесь написано. Потому что хорошо, когда есть явная ошибка. А при исправлении чужого кода легко получить мелкую неявную ошибку. Которая допущена в январе, но не проявится сразу, а проявится в декабре. И придется объяснять руководству, что нам надо открывать период и перезакрывать все месяца с начала года, с пересдачей отчетности.
Для управления критичными вещами надо выделять отдельное устройство (компьютер, телефон). На котором без необходимости не производится никаких изменений в софте, настройках и проч. Сам софт стоит минимально необходимый и ничего лишнего.
Я так понял, что она должна была написать код, потом показать результат его выполнения. Можно посмотреть код, который был создан в данном случае ?
Пожилому человеку (дееспособному) сложно разбираться в условиях договоров, личных кабинетах и проч. Все этим МБит/с, 5G и пр. ему ничего не говорят. История которая затронула моих родственников. Оператор проводной телефонной сети (он же и интернет) обзванивал людей и предлагал перейти на тариф с более быстрым интернетом. Скорее всего честно называл условия (что повысится абон плата). Пожилые люди не особо понимали что, тут происходит, но основном соглашались. Их переводили на тариф 500 МБит/с (+200 р к абон плате). Хотя если оператор делал хотя бы минимальный анализ трафика, такого предложения никогда не поступило бы. В моем случае реальная скорость на предоставленном оператором же роутере с WiFi типа N с учетом нахождения клиентского устройства за бетонной стеной была 20Мбит/с максимум. И такая конфигурация была несколько лет. Тариф переключили назад на минимально возможной, по поводу уже списанных денег претензию родственник писать не стал. После того как это выявилось, родственник пообщался с соседями и оказалось что аналогичное происходило у многих пожилых людей.
То же самое касается и выдачи телефонов несовершеннолетним детям.
По всем технически сложным услугам такие люди должны иметь возможность быть чисто пользователями и не более того. А не стороной договора. Не должно быть возможности войти в личный кабинет оператора по паролю через СМС на такой телефон и т.п.
Сейчас это возможно по сути только на корпоративном тарифе.
К ООО "Яндекс" надо бы добавить ИНН или ОГРН чтобы организация была четко определена. Потому что с таким названием организаций несколько. Можете зайти на https://egrul.nalog.ru и убедиться.