Т.е. все, что используется у вас для заказа — это текущий остаток?
Причем тут смены?
Как только закрыли смену — появился Z-отчет. Как только появился Z-отчет — у вас есть продажи смены и изменились остатки. Зачем остатки в он-лайне? Неужели в ответ будут только лозунги?
Не, ну если для вас это рядовая ситуация
Судя по вашим ответам — вас в рознице ждет еще масса «открытий» :)
Это говорит только о том, что в бэке сидит 100500 человек в системе (отдельный вопрос — что они там делают). Больше ни о чем :)
Вам для заказа остатки не нужны? Ну-ну.
А какое отношение остатки в он-лайн (подчеркиваю — в он-лайн!) имеют к заказам? Или у вас смены не закрываются? Или вы не знаете, что такое статистика продаж (ну хотя-бы за пару лет)?
И когда она не совпадает с ценой на ценнике — это ЧП, с разборками, ущербом для репутации и много чего еще.
Если у вас нет электронных ценников — это будет ВСЕГДА. И никакого ЧП, разбора и все прочего :) Это рядовая ситуация.
С 1к одновременных пользователей и автоматизацией всего что только можно.
Это на качество системы автоматизации практически не влияет. Хоть 30 тысяч, хоть 1 пользователь.
Остатки онлайн сокращают время принятия решения на 1 день
Каких решений? Каким образом?
Скоропорт анализируется в магазине. Там выгрузить продажи в бек — не составляет никаких проблем (но и это не надо). Для принятия решений по скоропорту — достаточно текущего оборота в открытой кассовой смене и статистики продаж. Повторюсь — зачем остатки в онлайне?
Как правило, если я правильно помню, в соответствующем АРМ, нажал распечатать, как только распечаталось (эта информация тоже сохраняется и анализируется) идет задание на загрузку в кассы.
ууу… просто для информации: в РФ (куда вы так стремитесь) есть только одно место для определения цены товара — это ценник в торговом зале. И цена во фронте никого не парит от слова «совсем» :)
И насчет не нужен, мы помню переводили одну сеть. У нас через час после задержек приема реализации звонили и ругались, почему остатки не актуальны. На аргумент, раньше у вас вообще в конце дня все принималось, ответ был: ну так к хорошему быстро привыкаешь.
Понятно :) А крупнее, чем ларьки, есть кто-то?
Т.е. осмысленного ответа, зачем изменение остатков в он-лайне в рознице — не будет?
Если вы про актуальность цен в кассе / на ценнике, то для этого есть отдельный процесс, который синхронизирует вынос ценника с успешной загрузкой в оборудование.
Почти все из перечисленного можно с успехом сделать на 7.7 (смотрите на тот же Астор со старыми Торговыми Сетями).
Онлайн прием данных из касс вам нафиг не уперся, кроме некоторых чисто презентационных фишечек. Для бизнеса он не нужен. С точки зрения автоматизации и решаемых задач: кэш-лайн и его управление — значительно более интересная область.
Если уж вы так прошарены в рознице — как вы решаете проблему изменения цен в магазине?
Понятно, что ген надо было несколько (и есть еще расходы). Но все равно — интересно :)
ЗЫ: Хотя вот про бомжей, употребляющих ДТ — это новое бесполезное знание в моей голове…
Т.е. если (например) .NET «из коробки»(!) не имеет объекта для плана видов характеристик (выражаясь 1с-ской терминологией) — то это будет архитектурный недостаток рантайма и реализация аналога на #-языке или любом другом — будет костыль, я правильно понял? А речь идет о банальной задаче (для 1с-ской платформы).
«написал на встроенном языке один раз и заработало везде одинаково»
А кто это анонсировал? Есть возможность написать компоненту, которая под одним интерфейсом «спрячет» работу с нативным API нужной ОС. При этом на тех осях, где компонента есть — будет работать одинаково, с точностью до реализации компоненты.
Очевидно, что автору компоненты надо будет приложить некоторый набор усилий. Если полная кроссплатформенность не нужна — ситуация пропорционально упрощается.
За чудеса кто-то обязательно должен заплатить, бесплатные чудеса — это фантастика :)
В общем да. Компоненты поддерживают работу на всех платформах, в вебе и на мобиле. В том смысле, что внешняя компонента может работать везде, где перечислил. Разработчик компоненты должен, естественно, про это помнить.
А я разве это отрицаю? Изначально (двумя постами выше) я вполне осмысленно и осознанно написал, что асинхронность в 1с сделана не очень хорошо.
Собственно все. Если 1с исправит положение вещей — все порадуются. Не исправит — будем пользовать то, что есть.
Даже на 7.7 делали большое количество разных (в том числе и тяжелых) внедрений. Понятно, что понятие о «тяжести» 20 лет назад и сейчас слегка разнятся, но тем не менее. А очень много народу «осталось» в начале 00-х, и оттуда вещает о дешевизне и непригодности 1С: Предприятия. Просто рынок базовой версии и проекта для какого-нибудь Камаза — они разные. И исполнители у этих проектов НИКОГДА не пересекутся.
И почему в результате гавном становится 1с, а не заказчик, жмущий бюджет? Почему вы переворачиваете ситуацию с ног на голову?
Замените «1С» на «lsFusion», «SAP», «Axapta» — что-то изменится? ИМХО — ничего. Только виноват все равно будет заказчик, жмущий бюджет, а не система на нормальное внедрение которой бюджет жмется.
Например тем, что XLS используется как входной формат для кого-то/чего-то другого.
И это все равно не отвечает на вопрос — зачем такой огромный XLS и почему «формулы» нельзя в 1С сделать, а отдать только результат. Тут вопрос в том, что в данный момент мне не ясна задача, а в текущем понимании Excel не очень нужен. Если там есть какие-то реальные ограничения — ок. Но пока ограничения не видны.
И что? Я не понимаю, куда вы клоните. Достаточно часто САП — это профанация и освоение бюджета. Когда годами внедряют САП, а учет ведут по-прежнему (например) в 1с. Потом или деньги кончаются или власть меняется и САП забывается или остается для материнской компании.
Изначально мы начали с того, что качество продукта никак не определяется количеством денег, который какой-то клиент хочет заплатить за услуги по продукту.
Переоценку утверждает уполномоченное лицо.
Т.е. все, что используется у вас для заказа — это текущий остаток?
Как только закрыли смену — появился Z-отчет. Как только появился Z-отчет — у вас есть продажи смены и изменились остатки. Зачем остатки в он-лайне? Неужели в ответ будут только лозунги?
Судя по вашим ответам — вас в рознице ждет еще масса «открытий» :)
Это говорит только о том, что в бэке сидит 100500 человек в системе (отдельный вопрос — что они там делают). Больше ни о чем :)
А какое отношение остатки в он-лайн (подчеркиваю — в он-лайн!) имеют к заказам? Или у вас смены не закрываются? Или вы не знаете, что такое статистика продаж (ну хотя-бы за пару лет)?
Если у вас нет электронных ценников — это будет ВСЕГДА. И никакого ЧП, разбора и все прочего :) Это рядовая ситуация.
Это на качество системы автоматизации практически не влияет. Хоть 30 тысяч, хоть 1 пользователь.
Каких решений? Каким образом?
Скоропорт анализируется в магазине. Там выгрузить продажи в бек — не составляет никаких проблем (но и это не надо). Для принятия решений по скоропорту — достаточно текущего оборота в открытой кассовой смене и статистики продаж. Повторюсь — зачем остатки в онлайне?
ууу… просто для информации: в РФ (куда вы так стремитесь) есть только одно место для определения цены товара — это ценник в торговом зале. И цена во фронте никого не парит от слова «совсем» :)
Понятно :) А крупнее, чем ларьки, есть кто-то?
Т.е. осмысленного ответа, зачем изменение остатков в он-лайне в рознице — не будет?
А что вперед? Вынос или выгрузка?
Онлайн прием данных из касс вам нафиг не уперся, кроме некоторых чисто презентационных фишечек. Для бизнеса он не нужен. С точки зрения автоматизации и решаемых задач: кэш-лайн и его управление — значительно более интересная область.
Если уж вы так прошарены в рознице — как вы решаете проблему изменения цен в магазине?
ЗЫ: Хотя вот про бомжей, употребляющих ДТ — это новое бесполезное знание в моей голове…
А кто это анонсировал? Есть возможность написать компоненту, которая под одним интерфейсом «спрячет» работу с нативным API нужной ОС. При этом на тех осях, где компонента есть — будет работать одинаково, с точностью до реализации компоненты.
Очевидно, что автору компоненты надо будет приложить некоторый набор усилий. Если полная кроссплатформенность не нужна — ситуация пропорционально упрощается.
За чудеса кто-то обязательно должен заплатить, бесплатные чудеса — это фантастика :)
Собственно все. Если 1с исправит положение вещей — все порадуются. Не исправит — будем пользовать то, что есть.
Хм… Интересно…
Замените «1С» на «lsFusion», «SAP», «Axapta» — что-то изменится? ИМХО — ничего. Только виноват все равно будет заказчик, жмущий бюджет, а не система на нормальное внедрение которой бюджет жмется.
Например тем, что XLS используется как входной формат для кого-то/чего-то другого.
И это все равно не отвечает на вопрос — зачем такой огромный XLS и почему «формулы» нельзя в 1С сделать, а отдать только результат. Тут вопрос в том, что в данный момент мне не ясна задача, а в текущем понимании Excel не очень нужен. Если там есть какие-то реальные ограничения — ок. Но пока ограничения не видны.
Изначально мы начали с того, что качество продукта никак не определяется количеством денег, который какой-то клиент хочет заплатить за услуги по продукту.