Вы предлагаете, что бы платформа применяла функцию Максимум(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 записи)
Отчет об текущих остатках на балансе Ozon из такой системы не получить. Да и вообще как узнать хотя бы общую сумму на балансе Ozon на конкретную дату без переноса остатков? Только смотреть в старой учетной системе и вручную складывать с новой?
Не понятно, как определяется "Текущее состояние". Например предполагаемое состояние "Выдача клиенту", текущее состояние неизвестно, т.к. остатки не переносились. Стоимость товара может принадлежать как внешнему интернет-магазину так и Ozon.
А для поддержки основной системы (не 1С) иметь в два раза больше разработчиков?
1с обходится намного дешевле, чем «пилить» свой систему с нуля. И на 1с задачи бизнеса решаются намного быстрее.
Какая разница, что вы будете контролировать: остатки на складах, партии или товары организаций если менеджер забыл сделать приход? Ни каких остатков не будет, ни тех, ни других. Нет операции прихода. А товар на полке есть и покупатель хочет его купить.
Насчет товаров организации и партий. Товар принадлежит одному владельцу, а продает другая организация. Перепродажи (интеркомпани) делаются уже после продажи конечному покупателю. Т.е. товар продается в минус по организации, по партиям вообще проводка не делается (УТ 10, УПП 1.3). Ну а по остаткам на складах, как я выше написал, просто забыли оприходовать.
Я говорю про то, что контролировать минусовые остатки в массовой рознице не нужно. Особенно поточной, когда на каждую кассу очередь по несколько человек.
Для мелких магазинов (организаций) нужен контроль. У них нет отдельного отдела товарного учета из 10-15 человек которые оперативно ежедневно выявляют минуса, пересорты и т.п. и исправляют
Ну пусть будет ТВ тысяч за 200. Вот он стоит. Покупатель хочет купить, а на остатках нет, т.к. менеджер забыл оприходовать, или не тот артикул оприходовал. Очень часто бывает, что менеджер по учету склада забывает на перемещение сделать приходный ордер.
Товар же в рознице должен быть продан здесь и сейчас. Представьте, что вы набрав тележку продуктов подъехали на кассу, а там вам половину не пробили, т.к. «не на остатках». Например в ПО SetRetail не было учета по остаткам несколько лет назад (на тот момент, когда мы внедряли).
В случае же заказа через интернет-магазин покупателю приходит оповещение «ваш заказ готов». Оно приходит после того, как менеджер интернет-магазина проверил наличие, сотрудники магазина отложили в сторонку (наклеили стикер «продано»).
Выбрал покупатель в торговом зале колечко с алмазами за 1 млн. Подходит на кассу, а там по учетной системе нет на остатках и вы ему: «приходите через пару дней, когда отдел товарного учета разберется». И покупателя потеряли, и 1 млн, и репутация понизилась…
В рознице не должно быть контроля минусов. С минусами разбирается отдел товарного учета после закрытия смены.
В опте должен быть контроль, т.к. в отличии от розницы (где товар вот он, на руках у покупателя) не известно, есть ли товар по факту.
Дома и на работе лучше работать за полноценным ПК/ноутбуком. Планшет нужен в редких случаях, когда приходится работать в другом месте, например на отдыхе.
К планшету нужно относится как «терминалу». Арендуем VPS, ставим туда IDE и подключаемся с планшета по VNC/RDP/AnyDesk и т.п. (или разворачиваем Code Server). К планшету естественно чехол с клавиатурой. Получается очень легкий «ноутбук» за которым можно полноценно работать.
Так же на планшет можно поставить linux (например через UserLAnd) и туда поставить VS code. В этом случае нужен достаточно мощный планшет.
Самое интересно, что в этой новости указанно:
"… новая цена планшета ASUS Vivo Tab RT составит $549, а самое главное, каждый покупатель бесплатно получает док-клавиатуру, которая стоит $199.."
Да и ранее везде цена озвучивалась на уровне 600$…
Вы предлагаете, что бы платформа применяла функцию Максимум(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 для коммерческих проектов?
Отчет об текущих остатках на балансе Ozon из такой системы не получить. Да и вообще как узнать хотя бы общую сумму на балансе Ozon на конкретную дату без переноса остатков? Только смотреть в старой учетной системе и вручную складывать с новой?
Не понятно, как определяется "Текущее состояние". Например предполагаемое состояние "Выдача клиенту", текущее состояние неизвестно, т.к. остатки не переносились. Стоимость товара может принадлежать как внешнему интернет-магазину так и Ozon.
1с обходится намного дешевле, чем «пилить» свой систему с нуля. И на 1с задачи бизнеса решаются намного быстрее.
Насчет товаров организации и партий. Товар принадлежит одному владельцу, а продает другая организация. Перепродажи (интеркомпани) делаются уже после продажи конечному покупателю. Т.е. товар продается в минус по организации, по партиям вообще проводка не делается (УТ 10, УПП 1.3). Ну а по остаткам на складах, как я выше написал, просто забыли оприходовать.
Я говорю про то, что контролировать минусовые остатки в массовой рознице не нужно. Особенно поточной, когда на каждую кассу очередь по несколько человек.
Для мелких магазинов (организаций) нужен контроль. У них нет отдельного отдела товарного учета из 10-15 человек которые оперативно ежедневно выявляют минуса, пересорты и т.п. и исправляют
Товар же в рознице должен быть продан здесь и сейчас. Представьте, что вы набрав тележку продуктов подъехали на кассу, а там вам половину не пробили, т.к. «не на остатках». Например в ПО SetRetail не было учета по остаткам несколько лет назад (на тот момент, когда мы внедряли).
В случае же заказа через интернет-магазин покупателю приходит оповещение «ваш заказ готов». Оно приходит после того, как менеджер интернет-магазина проверил наличие, сотрудники магазина отложили в сторонку (наклеили стикер «продано»).
В рознице не должно быть контроля минусов. С минусами разбирается отдел товарного учета после закрытия смены.
В опте должен быть контроль, т.к. в отличии от розницы (где товар вот он, на руках у покупателя) не известно, есть ли товар по факту.
К планшету нужно относится как «терминалу». Арендуем VPS, ставим туда IDE и подключаемся с планшета по VNC/RDP/AnyDesk и т.п. (или разворачиваем Code Server). К планшету естественно чехол с клавиатурой. Получается очень легкий «ноутбук» за которым можно полноценно работать.
Так же на планшет можно поставить linux (например через UserLAnd) и туда поставить VS code. В этом случае нужен достаточно мощный планшет.
"… новая цена планшета ASUS Vivo Tab RT составит $549, а самое главное, каждый покупатель бесплатно получает док-клавиатуру, которая стоит $199.."
Да и ранее везде цена озвучивалась на уровне 600$…