Из главы 16 не понял как все таки аутентифицировать пользователей обращающихся к API.
Например есть 1 млн пользователей и функция API которая возвращает каждому пользователю только его записи из одной общей таблицы БД.
Нужно же все 1 млн пользователей зарегистрировать в системе. Потом каждому каким то образом выдавать токен, токен передавать в функцию API и там определять по токену записи в таблице и возвращать их.
Вопрос в задаче идет про текущий день. Следовательно текущий день является точкой отсчета и от него отсчитываем все дни (т.е. "следующий" в задаче - это следующий за текущем днем, а не за завтрашним). Получаем:
вчера -> текущий день? -> следующий день (он же завтрашний).
Если бы вчерашний день был завтрашним, то следующий день был бы воскресеньем. Т.к. следующий день = завтрашний, а завтрашний = вчерашнему, то вчерашний день - Воскресенье.
Если вчера было воскресенье, то сегодня понедельник.
Если же следовать вашей логике и принять что завтрашний=следующий, то ответ суббота.
Посмотрел тарифы. На 500 одновременных пользователей явно маловато будет, значит стоимость от 269$ в месяц. Не дешевле написать свой бэк и VPS арендовать? Плюс риски, что данный сервис перестанет работать в России.
Получается, что вы осознано выбираете более худшую архитектуру и жертвуете качеством ради быстрого добавления новых фич. А увеличение численности команды модуля "Accounts" не ускорит разработку?
Увеличил, что бы было лучше видно лицо. Этой сети только для ужастиков придумывать иллюстрации ). Ни одной картинки соответствующей моим запросам сеть не сделала.
1С не обеднела бы, если бы для клиентов с оборотом до 30 тысяч рублей в месяц или до 80 тысяч в год программа была бы бесплатной
Вы работаете бесплатно на организации с оборотом до 30 т.р. в месяц? Почему бизнес что то должен делать бесплатно? Я не видел, что бы в поселке/городе всем, у кого зп небольшие, выдавали хлеб бесплатно например.
В России есть много аналогов 1с по разным ценам, есть наверное и бесплатные. Пользуйтесь ими или пишите свою учетную систему.
Вы предлагаете, что бы платформа применяла функцию Максимум(0, Остаток) при чтении остатка из регистра накопления.
Но то, что при чтении (например при выводе отчета) вы уберете минус, от этого он не исчезнет из регистра. Там же просто математика: приход - расход.
Если же вы хотите применять функцию Максимум при записи в регистр, то это еще более бессмысленно. В вашем же примере, когда из заказа убрали апельсины, которые продали и получился минус по резерву. При проведении измененного заказа минус в регистр же не записывается, просто убирается запись прихода на момент заказа. А реализация как делала расход так и делает, пока мы ее не перепроведем.
Можете на примере своих апельсинов привести пример как платформа должна не дать сделать минус?
Если вы про реализацию, которая списывала резерве, то нужно ее перепровести, что бы резерв не списывался, т.к. резерва нет.
Можете проверить это все на любой конфигурации УТ 10, УТ 11, УПП 1.3, ЕРП 2.х . Только ЕРП и УТ 11 вам не даст просто так изменить документ в минус, т.к. идет контроль остатков на текущую дату и нужно менять все документы начиная с последнего в цепочке.
Не вижу смысла в дальнейшей переписке, такое ощущение, что вы хотите что бы я научил вас вести учет.
Просто меняются данные в заказе. Тут же подразумевается что реализации апельсина еще не было, ведь клиент его не заказывал? А если заказывал, то почему мы должны убирать их из заказа?
Я не понимаю к чему ваши все вопросы. В статье указано, что проблемы минусов по регистрам нужно решать на уровне платформы. Я привел конкретный пример и спросил как вы предлагаете это решать технически в платформе. Вместо ответа вы задаете мне общие вопросы по учету не имеющие отношения к технической части.
Не понятно как это относится к моему вопросу, на который вы написали ответ.
На ваш вопрос ответ:
Движение по регистру резервов зависит от того, был ли в заказе покупателя установлен резерв или нет. Если не было резервирования в заказе, то никак не нужно отражать.
Если заказ делал резерв 2 шт (приход по регистру), то реализация делает расход по резерву 2 шт
Не написана причина появления минусов (откуда минус по резервам?), а следовательно и дальнейшие рассуждения не имеют ценности. Теория оторванная от реальности.
А минусы появляются например так:
Менеджер по закупкам приходует 10 шт. товара. Менеджер по продажам через месяц продает 10 шт товара. В конце квартала/года, при сверке первичных документов оказывается, что поступило не 10 шт, а 8 шт, менеджер ошибся занося в 1с документ. Бухгалтер требует срочно привести с/ф в соответствие. Поступление исправляется на 8 шт. и получаем -2 шт. на остатке.
Как продали 10 шт. если было всего 8 шт.? Просто был пересорт на складе, физически товар был в наличии вот и продали.
Как вы предлагаете программнно бороться с данными минусами?
Почему все советуют пользоваться Winpinator/Warpinator?
На SteamDeck есть же служба ssh (sftp), которая работает и в игровом режиме (не нужно переключаться на рабочий стол), можно по всем директориям перемещаться и в любую файлы закидывать.
Реальные запросы типа "Стоимость остатков склада в продажной цене","какие плановые платежи на март запланированы" или "валовая прибыль и рентабельность за прошлый месяц по группе фрукты" данная система может отработать?
Как то на первый взгляд плохо кажется с точки зрения оптимизации. Почему условия не указываются в параметрах виртуальной таблицы? Например 150 000 SKU (уникальных номенклатур в справочнике) и 100 скадов. Сначала будут перебираться десятки тысяч записей и потом на результат будет наложен отбор (итогом всего запроса например будет всего 3 записи)
Из главы 16 не понял как все таки аутентифицировать пользователей обращающихся к API.
Например есть 1 млн пользователей и функция API которая возвращает каждому пользователю только его записи из одной общей таблицы БД.
Нужно же все 1 млн пользователей зарегистрировать в системе. Потом каждому каким то образом выдавать токен, токен передавать в функцию API и там определять по токену записи в таблице и возвращать их.
Так?
Вопрос в задаче идет про текущий день. Следовательно текущий день является точкой отсчета и от него отсчитываем все дни (т.е. "следующий" в задаче - это следующий за текущем днем, а не за завтрашним). Получаем:
вчера -> текущий день? -> следующий день (он же завтрашний).
Если бы вчерашний день был завтрашним, то следующий день был бы воскресеньем. Т.к. следующий день = завтрашний, а завтрашний = вчерашнему, то вчерашний день - Воскресенье.
Если вчера было воскресенье, то сегодня понедельник.
Если же следовать вашей логике и принять что завтрашний=следующий, то ответ суббота.
Почему в исследованиях очень редко пишут про Хабаровск или Владивосток (столицу Дальнего Востока)?
"Steam" это получается бэкенд для приложения?
Посмотрел тарифы. На 500 одновременных пользователей явно маловато будет, значит стоимость от 269$ в месяц. Не дешевле написать свой бэк и VPS арендовать? Плюс риски, что данный сервис перестанет работать в России.
Получается, что вы осознано выбираете более худшую архитектуру и жертвуете качеством ради быстрого добавления новых фич. А увеличение численности команды модуля "Accounts" не ускорит разработку?
Как у бота обстоит дело с конфиденциальностью? Вы ведь пишите все запросы и ответы в БД?
Почему под ответом бота кнопка "Generate images and text without limits" которая перекидывает на другого бота?
Увеличил, что бы было лучше видно лицо. Этой сети только для ужастиков придумывать иллюстрации ). Ни одной картинки соответствующей моим запросам сеть не сделала.
Вы работаете бесплатно на организации с оборотом до 30 т.р. в месяц? Почему бизнес что то должен делать бесплатно? Я не видел, что бы в поселке/городе всем, у кого зп небольшие, выдавали хлеб бесплатно например.
В России есть много аналогов 1с по разным ценам, есть наверное и бесплатные. Пользуйтесь ими или пишите свою учетную систему.
Вы предлагаете, что бы платформа применяла функцию Максимум(0, Остаток) при чтении остатка из регистра накопления.
Но то, что при чтении (например при выводе отчета) вы уберете минус, от этого он не исчезнет из регистра. Там же просто математика: приход - расход.
Если же вы хотите применять функцию Максимум при записи в регистр, то это еще более бессмысленно. В вашем же примере, когда из заказа убрали апельсины, которые продали и получился минус по резерву. При проведении измененного заказа минус в регистр же не записывается, просто убирается запись прихода на момент заказа. А реализация как делала расход так и делает, пока мы ее не перепроведем.
Можете на примере своих апельсинов привести пример как платформа должна не дать сделать минус?
Если вы про реализацию, которая списывала резерве, то нужно ее перепровести, что бы резерв не списывался, т.к. резерва нет.
Можете проверить это все на любой конфигурации УТ 10, УТ 11, УПП 1.3, ЕРП 2.х . Только ЕРП и УТ 11 вам не даст просто так изменить документ в минус, т.к. идет контроль остатков на текущую дату и нужно менять все документы начиная с последнего в цепочке.
Не вижу смысла в дальнейшей переписке, такое ощущение, что вы хотите что бы я научил вас вести учет.
Просто меняются данные в заказе. Тут же подразумевается что реализации апельсина еще не было, ведь клиент его не заказывал? А если заказывал, то почему мы должны убирать их из заказа?
Я не понимаю к чему ваши все вопросы. В статье указано, что проблемы минусов по регистрам нужно решать на уровне платформы. Я привел конкретный пример и спросил как вы предлагаете это решать технически в платформе. Вместо ответа вы задаете мне общие вопросы по учету не имеющие отношения к технической части.
вы задаете вопросы по базовому оперативному учету, как это относится к 1с?
Если в заказе был резерв 1 шт, а в реализации продано 2 шт, то реализация делает по регистру резвов -1 шт, еще 1 шт, просто со склада, а не с резерва
Не понятно как это относится к моему вопросу, на который вы написали ответ.
На ваш вопрос ответ:
Движение по регистру резервов зависит от того, был ли в заказе покупателя установлен резерв или нет. Если не было резервирования в заказе, то никак не нужно отражать.
Если заказ делал резерв 2 шт (приход по регистру), то реализация делает расход по резерву 2 шт
Не написана причина появления минусов (откуда минус по резервам?), а следовательно и дальнейшие рассуждения не имеют ценности. Теория оторванная от реальности.
А минусы появляются например так:
Менеджер по закупкам приходует 10 шт. товара. Менеджер по продажам через месяц продает 10 шт товара. В конце квартала/года, при сверке первичных документов оказывается, что поступило не 10 шт, а 8 шт, менеджер ошибся занося в 1с документ. Бухгалтер требует срочно привести с/ф в соответствие. Поступление исправляется на 8 шт. и получаем -2 шт. на остатке.
Как продали 10 шт. если было всего 8 шт.? Просто был пересорт на складе, физически товар был в наличии вот и продали.
Как вы предлагаете программнно бороться с данными минусами?
Почему все советуют пользоваться Winpinator/Warpinator?
На SteamDeck есть же служба ssh (sftp), которая работает и в игровом режиме (не нужно переключаться на рабочий стол), можно по всем директориям перемещаться и в любую файлы закидывать.
Реальные запросы типа "Стоимость остатков склада в продажной цене","какие плановые платежи на март запланированы" или "валовая прибыль и рентабельность за прошлый месяц по группе фрукты" данная система может отработать?
Как то на первый взгляд плохо кажется с точки зрения оптимизации. Почему условия не указываются в параметрах виртуальной таблицы? Например 150 000 SKU (уникальных номенклатур в справочнике) и 100 скадов. Сначала будут перебираться десятки тысяч записей и потом на результат будет наложен отбор (итогом всего запроса например будет всего 3 записи)
Вы пишите про PyQt и PySide. Это просто прокси библиотеки для обращения к Qt. Т.е. нужна еще сама Qt, а на сайте Qt расписаны только платные лицензии.
Я задавался этим вопросом лицензирования когда выбирал GUI для Python, но ответа так и не нашел...
PySide бесплатна, а нужно ли покупать лицензию на сам Qt для коммерческих проектов?