Comments 53
История интересная, но у меня вопрос из «области общих знаний» :)
По моим воспоминаниям из прошлой жизни, вот такое требование:
в основном нужно для гордой демонстрации, и слабо нужно для реальной жизни.
Т.е. когда люди хотят оперативно иметь z-отчеты — понятно, когда чеки используются в системах лояльности — тоже плюс/минус понятно, а вот когда для «оперативного принятия управленческих решений» — тогда не очень
А ваш клиент озвучил, зачем ему данные с такой точностью? Или мои воспоминания можно сдать в архив и чековая лента из 650-ти точек в базе может чему-то реальному помочь?
По моим воспоминаниям из прошлой жизни, вот такое требование:
чеки, пробитые на кассе магазина, должны быть видны в центральной системе 1С не более, чем через 1 секунду от момента его «фискализации» на кассе при наличии (исправной работе) связи
в основном нужно для гордой демонстрации, и слабо нужно для реальной жизни.
Т.е. когда люди хотят оперативно иметь z-отчеты — понятно, когда чеки используются в системах лояльности — тоже плюс/минус понятно, а вот когда для «оперативного принятия управленческих решений» — тогда не очень
А ваш клиент озвучил, зачем ему данные с такой точностью? Или мои воспоминания можно сдать в архив и чековая лента из 650-ти точек в базе может чему-то реальному помочь?
Чеки нужны оперативно. Зачем — ну можно много придумать зачем. Те же резервы товаров, например. В данном конкретном случае, 1 секунда это не бизнес-критичная величина. И 1.5 секунды и 5 секунд, на самом деле, подойдут. Просто у нас получалось за секунду. Не замедлять же теперь )
Придумывать неинтересно :) Резервы в продуктах на розничных точках — это что-то новое :)
Андрей, речь не о вашем решении, как таковом. Речь идет о том, чем заказчик мотивировал необходимость такой оперативности обменов.
Если вы не вникали и решали такую задачу просто как технологический вызов — это тоже ответ и он ± понятен.
Андрей, речь не о вашем решении, как таковом. Речь идет о том, чем заказчик мотивировал необходимость такой оперативности обменов.
Если вы не вникали и решали такую задачу просто как технологический вызов — это тоже ответ и он ± понятен.
Резервы в продуктах на розничных точках — это что-то новое
Видимо вы мало работали с ритейлом. Обычное дело, вообще-то. Разве что с едой пример неудачный. А в целом по торговле — запросто.
«Просто технологический вызов» — это мимо. Любое внедрение начинается с целей, это аксиома. Я не участвовал на самом старте проекта и природу цифры в 1сек. уже не назову (или напутаю). Думаю, коллеги, которые больше в теме, подтянутся в топик и расскажут.
UFO just landed and posted this here
UFO just landed and posted this here
Переоценка. Несколько раз в день. А вот интересно как заказчик проблему с ценниками решил?
— Продавцы эти (бумажные) ценники несколько раз в день переписывают?
— Покупателю если что говорят «Вы мне ценник и что там — дешевле, не показывайте! У нас в базе другая цена! Компьютер не может продать по той что на ценнике» (при том что по закону — должны продать по цене на ценнике...)
— Ценники сами обновляются с того самого компьютера товароведа (потому что они на eInk).
Ой что-то мало верится в последний вариант. Больше — во второй.
— Продавцы эти (бумажные) ценники несколько раз в день переписывают?
— Покупателю если что говорят «Вы мне ценник и что там — дешевле, не показывайте! У нас в базе другая цена! Компьютер не может продать по той что на ценнике» (при том что по закону — должны продать по цене на ценнике...)
— Ценники сами обновляются с того самого компьютера товароведа (потому что они на eInk).
Ой что-то мало верится в последний вариант. Больше — во второй.
Непонятно, зачем было тянуть полифиллы в кассовое ПО. Если там есть поддержка ES3 — ее вполне достаточно, чтобы выбрать данные о чеке и переслать их дальше. Добавление ES5/6 выглядит как бессмысленное усложнение. Тем более что ничего незаменимого там не добавлено. Или ваши разработчики не знают отличий версий JS и не способы писать под определенную версию?
Я наверное непонятно донес. Там не JS, там весьма специфичное микрософтовское видение этого языка. Там даже не ES3
там даже до es3 было далеко. Это майкрософтовский JScript ХРшного разлива с выпиленными библиотеками к тому же. Там не то, что какого-нибудь Math нет, там даже JSON пришлось целиком полифилить
Где-то треть полифилов была добавлена действительно для удобства эээ меня в том числе, как привыкшего к typescript и es6 и с содраганием вспоминающего эпоху pre-es5. Но остальное приходилось добавлять для реально нужных вещей или для работы других более высокоуровневых полифилов (не переписывать же официально рекомендованные от Mozilla)
Если честно, я не понимаю изначального «наезда». Ну скопипастили несколько готовых полифилов, они все упакованы в немешающие функции где-то «внизу», на производительность влияют минимально, а скорость и стоимостью разработки сокращают. В чем проблема-то?
P. S. На скриншотах в статье не все полифилы, которые были добавлены.
Где-то треть полифилов была добавлена действительно для удобства эээ меня в том числе, как привыкшего к typescript и es6 и с содраганием вспоминающего эпоху pre-es5. Но остальное приходилось добавлять для реально нужных вещей или для работы других более высокоуровневых полифилов (не переписывать же официально рекомендованные от Mozilla)
Если честно, я не понимаю изначального «наезда». Ну скопипастили несколько готовых полифилов, они все упакованы в немешающие функции где-то «внизу», на производительность влияют минимально, а скорость и стоимостью разработки сокращают. В чем проблема-то?
P. S. На скриншотах в статье не все полифилы, которые были добавлены.
Интересно было бы узнать исходную бизнес-задачу.
С технической стороны все в выигрыше — и клиент доволен, и исполнитель за счёт клиента «прокачался».
С технической стороны все в выигрыше — и клиент доволен, и исполнитель за счёт клиента «прокачался».
UFO just landed and posted this here
Я к тому, что в исходной задаче, например, было не 1 секунда, а 1 минута. И тогда логичен вопрос — а стоило ли такой огород городить? Но решение хорошее, конечно, знание что «так можно» пригодиться.
Вообще-то очереди сообщений, это давно известный и общеупотребимый паттерн.
Насчет оперативности, ну представьте, что вы торгуете чем-нибудь в розницу и у вас 4000+ торговых точек по стране. Кроме того, люди покупают товары у вас на вашем же сайте и оформляют там доставку. Покупает человек, например, розовый айфон с доставкой. Откуда ему удобнее привезти? С центрального склада за 2-3 дня? Или с магазина в его собственном же подъезде, сократив таким образом расходы на логистику и обеспечив сервис «доставка за 20 минут»?
Чтобы такое сделать- вам нужно оперативно понимать, какие остатки розовых айфонов есть магазинах поблизости, зарезервировать на какое-то время, пока толпа других страждущих розовый айфон тоже серфит сайт, ну и т.п.
Сразу скажу, что с появлением онлайн-продаж возникает столько возможных кейсов, что я устану перечислять. Вплоть до мониторинга работы магазина.
Можно ли называть это «огородом»? Обычно это называют качественным преимуществом.
Насчет оперативности, ну представьте, что вы торгуете чем-нибудь в розницу и у вас 4000+ торговых точек по стране. Кроме того, люди покупают товары у вас на вашем же сайте и оформляют там доставку. Покупает человек, например, розовый айфон с доставкой. Откуда ему удобнее привезти? С центрального склада за 2-3 дня? Или с магазина в его собственном же подъезде, сократив таким образом расходы на логистику и обеспечив сервис «доставка за 20 минут»?
Чтобы такое сделать- вам нужно оперативно понимать, какие остатки розовых айфонов есть магазинах поблизости, зарезервировать на какое-то время, пока толпа других страждущих розовый айфон тоже серфит сайт, ну и т.п.
Сразу скажу, что с появлением онлайн-продаж возникает столько возможных кейсов, что я устану перечислять. Вплоть до мониторинга работы магазина.
Можно ли называть это «огородом»? Обычно это называют качественным преимуществом.
Есть альтернатива — работа всех точек в общей базе, например Деловые линии пошли по такому пути. Ну и доставку в течении минуты можно и без очередей обеспечить. Если реально надо в течении секунды — да, скорее всего альтернатив очередям нет.
Не забывайте про разные торговые точки.
Были точки на селе, или на окраинах, где простые 3G-свистки, частенько работающие в режиме 2G.
Какая уж тут ЕБД??
Были точки на селе, или на окраинах, где простые 3G-свистки, частенько работающие в режиме 2G.
Какая уж тут ЕБД??
Я безгранично уважаю ДЛ за умение работать с большой ЕБД на 1С в режиме Highload 24/7. Мой прагматизм говорит, что проще делать распределенные системы. Но это я исключительно за себя говорю. Возможно, ДЛ когда-нибудь опубликуют цифры — во что им обходится владение их системой. Я на коленке считал ЕБД vs МиниСервисы — получилось в пользу сервисов.
UFO just landed and posted this here
Про ритейлера с единой базой — этот случай? infostart.ru/public/857978
Если этот — то они вроде как всем довольны :)
Если этот — то они вроде как всем довольны :)
Я конечно понимаю желание, когда хочется все сделать на встроенных компонентах системы, но всегда наступает момент выбора, или добавлять новый внешний компонент, или продолжать пытаться запихать сложный функционал в эту древнюю систему.
В итоге вы добавляете внешние компоненты для .NET и ODBC-провайдер на кассы, и при этом продолжаете писать магию на встроенном Jscript. Что мешало написать свой .net-класс и его вызвать из Jscript.
В любом случае будет наступание на грабли, как развернуть на все кассы .net-компоненты
В итоге вы добавляете внешние компоненты для .NET и ODBC-провайдер на кассы, и при этом продолжаете писать магию на встроенном Jscript. Что мешало написать свой .net-класс и его вызвать из Jscript.
В любом случае будет наступание на грабли, как развернуть на все кассы .net-компоненты
Магия JS была обусловлена тем, что Фронтол позволяет его использовать.
В итоге было разделение — Net-часть обеспечивала работу с кроликом, а JS-часть — специфику Фронтола + обращение к серверу Кролика.
Мы как раз не стали смешивать в единую компоненту специфику Фронтола и специфику кролика.
В итоге было разделение — Net-часть обеспечивала работу с кроликом, а JS-часть — специфику Фронтола + обращение к серверу Кролика.
Мы как раз не стали смешивать в единую компоненту специфику Фронтола и специфику кролика.
Ну блин… Писать текстовые сценарии всяко же проще, чем компилируемые сборки, не?
А пробовали ли для отправки сообщений использовать REST-интерфейс Рэббита? Сейчас хотим запустить своими силами интеграцию 1Ски с шиной — подписку на сообщения я реализую через прокси-сервер на Java, а вот отправку похоже что придется делать через REST.
Не советую. Rest не обеспечит вам ту пропускную способность, которую даст чистый amqp. Да еще и писать прокси-сервер. Кажется что дешевле будет просто купить наш адаптер к 1С
Обращались к вам. Мое руководство отложило все на 4й квартал (возможно). Поэтому быстрее свое решение сделать.
А как вам решение Связного?(привет бывшим коллегам).
А как вам решение Связного?(привет бывшим коллегам).
Странное руководство у вас. Написать с нуля и отладить сервер, обучить админов его поддержке и мониторингу, передать падаванам компетенции по его развитию… Все это быстрее и дешевле покупки компоненты ценой в ползарплаты программиста?
Решение Связного также содержит внешний сервер и требует governance со стороны Java команды. А так хорошее решение все пользуются.
Решение Связного также содержит внешний сервер и требует governance со стороны Java команды. А так хорошее решение все пользуются.
UFO just landed and posted this here
UFO just landed and posted this here
Если мне память не изменяет, то в итоговой схеме федеративную очередь если не полностью выпилили, то минимизировали её использование и максимально задействовали showel (конкурс на лучший перевод этого слова). И наверное стоило добавить что был реализован еще и обратный канал: установка цен номенклатуры из центра.
Поясните такие моменты.
1) С вводом онлайн касс у нас все ведущие поставщики касс имеют на борту ФН с отправкой данных напрямую в ОФД. Данные по чекам можно брать через их API. Или у вас ОФД без API? Вторая приходящая в голову причина — требуется детализация чека в разрезе содержания в нем товарных позиций. Или вы этот самый внутренний ОФД писали?
2) Как решается вопрос с длительной недоступностью кассы (по сути данных с неё), больше суток допустим, и построением отчета? Ведь он по сути искажен. Делалась ли какая подсветка/подсказка в духе "… по данным с ХХ% касс"? Делалась ли какая-то агрегация данных (часовая? суточная? месячная?) для отчетов данные по котором 100% докатились до центральной системы?
1) С вводом онлайн касс у нас все ведущие поставщики касс имеют на борту ФН с отправкой данных напрямую в ОФД. Данные по чекам можно брать через их API. Или у вас ОФД без API? Вторая приходящая в голову причина — требуется детализация чека в разрезе содержания в нем товарных позиций. Или вы этот самый внутренний ОФД писали?
2) Как решается вопрос с длительной недоступностью кассы (по сути данных с неё), больше суток допустим, и построением отчета? Ведь он по сути искажен. Делалась ли какая подсветка/подсказка в духе "… по данным с ХХ% касс"? Делалась ли какая-то агрегация данных (часовая? суточная? месячная?) для отчетов данные по котором 100% докатились до центральной системы?
1) Эта история была до появления ОФД и онлайн-касс. Как сейчас обстоит дело, я не знаю.
2) отчеты были самые разные, в том числе и по "недогруженным кассам", но вообще — принимать какие-то стратегические решения по оперативным данным в течение дня, это вообще странноватое занятие. День в учете не зря формальным образом "закрывается" z-отчетом кассы. Даже безо всякой недоступности кто-то может просто придти и сделать возврат товара например.
UFO just landed and posted this here
А я правильно понимаю, что плагин Federation по сути использовался для организации кластера и коробочный механизм кластеризации erlang-а не использовался? И очередь внутри RMQ находящегося в POS кассе (под управлением WinXP) через этот плагин просто переливалась в другую очередь другого RMQ сервера в моменты когда связь с торговой точкой восстанавливалась? А пока со связью были перебои пробитые чеки копились в RMQ кассы (по сути реализация ФН)?
Sign up to leave a comment.
Онлайн-чеки по федеральной сети посредством RabbitMQ, 1С и черной магии