MAGAZKA - программа для розничного магазина от разработчика : Кассы 1С

Сорри... я не увидел твоего поста выше. Обязательно отвечу

Конфигурация написана с "0"
Изначально, была МАГАЗЬКА на 7.7 - она универсальная и под размерные ряды и безразмерные
на 8 -ке это две отдельные конфигурации

Что с клонированием РИБов, с обменами - на сколько далеко и как хорошо всё оптимизировано от штатных механизмов?

Сделан свой механизм полного обмена - локальный, через FTP, почту или яндек.диск
но пользователям больше полюбился через "ОБЛАКО"
ставим приложение Яндекс.Диск - логин и пароль
в настройке обмена - ЛОКАЛЬНО - указываем папку ЯНДЕКС.ДИСК

Примеры объема данных и время обменов на сетках магазинов для РИБа и ЦБ?

я им рекомендую 1800 секунд обмен, но кто то ставит и чаще
37 магазинов есть фирма - третий год работают (это самый большой)
как правило большинство клиентов это ДОМ - МАГАЗИН- МАГАЗИН

Как в РИБах работает механизм для автоматического принятия изменений конфигурации?

ЦБ - обновляется на новый релиз - обработка "ОБНОВЛЕНИЕ РЕЛИЗА" - скачали файл zip архив
указали - программа сама закрывается, делает бэкап, обновляется и сама запускается
при первом обмен отдает все измения ПБ.
Пользователю делать не нужно ничего вообще - программы выдаст сообщения "Обнаружено обновление конфигурации.Обновить или отложить ?"
Нажимает ОБНОВИТЬ- программа все сделает самостоятельно

На какой объем РИБов теоретически потянет ваша конфигурация и сколько максимум на практике был/есть?

максимум 38 узлов - это об котором я знаю.

РИБы только файловые или при каких то условиях загоняются на SQL? До какого размера растут?

только файловые

Какое железо требуется для адекватной производительности когда в чеках 10-20 позиций со сложными алгоритмами расчета/применения бонусов, скидок и т.п.?

Простой "офисный" компьютер или ноутбук - 100 чеков в день - обмен около 80 кб.

Часто ли падают файловые РИБы со всякими ошибками потока, dbeng, повреждением 1CD, NULL в таблицах и т.п.? Как лечите?

раз в месяц у 2 из 300 бывает только "dbeng" -

все самостоятельно восстанавливают : все описано на форуме:

"Ошибка СУБД: Внутренняя ошибка компоненты dbeng8" или ТО для вашей базы"

Или если уж вообще никак - по удаленке подключаюсь и "закрываю" данный вопрос. Чистка кэша или пересоздания РИБ

Есть обмен по расписанию и фоновый обмен

Что с ЕГАИС-ом?

Ходили слухи, что МАГАЗЬКА - классная программа, но ... не совсем для продуктовой розницы. Это так?

Хороший вопрос. Спасибо !

MAGAZKA - никогда не претендовала на продукты и алкоголь
(хотя и с этим успешно справляется)

из разряда "всем нужно , но ни кому не надо"

Штатно - ЕГАИСа нет в конфигурации.
Но, есть внешний модуль от сторонних разработчиков - адаптированный под MAGAZKA . Цена вопроса : 7000 руб.

Сделали - довели до сведения пользователей и никому не нужно стало... Было бы бесплатно это да, а так ... как нибудь !

Но , много, очень много работают с пивом !

Лицензия на программу - не включает в себя НЕОБХОДИМУЮ пользователю лицензию на 1С?
При покупке одной лицензии - сколько копий программы получится запустить?

Конфигурация - "открытая"?

Наверняка есть "лучшие практики" - до скольких пользователей можно работать в файловом варианте, когда необходимо переходить на клиент-серверное решение?

Есть опыт интеграции с БП 2.0, БП 3.0?

MAGAZKA, У нас Розница 1.0 с довольно большим объемом доработок. Сейчас 73 узла, хотя в максимуме работало 80 с чем то, точно не помню. Я планировал, что без каких-либо изменений можно спокойно жить до 150 узлов, а вот дальше уже пришлось бы кое что выносить из обменов, например карты и бонусы.
Я сам не разработчик, но скорее заказчик-администратор базы-тех поддержка 1/2/3 линии и тп. Но не программист)

В РИБах так же, 1800 секунд период обмена, а сам обмен в среднем длится в районе 10-15 секунд (загрузка/выгрузка). В ЦБ обмен в среднем раз в 40 минут со всеми узлами разом. В течение дня в среднем длится около 5 минут, а первый утренний около 20 минут, хотя зависит больше от того как вчера поторговали. Всё через FTP в пассивном режиме.
Вот РИБы периодически падают на обменах. Очень редко в течение дня, чаще всего при первом утреннем обмене когда грузится большой объем данных. Ну и все РИБы на SSD работают, говорят на них dbeng намного чаще в файловых базах вылетает чем на HDD. А может еще Win10 подсирает, не знаю. Как середина месяца и начинают обновления винды приходить, так активность падения баз резко возрастает. Затем на пол месяца почти полное затишье.
Ну и да, обычно это dbeng, но за почти 2 года один раз встречал ошибку потока и один раз NULL в таблицах. Правда я не держал свечку, что в магазине происходило, может и питание дергали.
Если это dbeng утром, то 98% вероятность, что в базе разрушился отчет о розничных продажах за последнюю смену. Не знаю в чем прикол, просто как факт. Чеки ни разу не страдали из-за проблем с базой. А лечение обычное, chdbfl и восстановление потерянных данных из ЦБ. Изредка, если в РИБе обмен по какой-то причине не работал, то приходится вручную смену перезакрывать через эмулятор.


Ну в целом у нас похоже, обновили конфигурацию ЦБ, всё разлетелось в РИБы и там автоматическое обновление. Но правда без предложений отложить.
Обновление всегда приходит утром при открытии магазина, включают "кассу", база сама запускается с обменом, прилетает обновление, жмешь ОК и дальше работает батник - закрывает базу, обновляет конфиг, запускает базу. Если больше одного пользователя в базе, то обновление само отложится пока не будет монопольного режима.


А как дела с маркировкой на практике, кто-то из клиентов у себя уже опробовал? Или пока всё на стадии "подготовлено, но нет желающих"?
У нас одежда, в след году часть верхней одежды под маркировку попадает, придется вникать в эту историю :(


или с УНФ/УТ и т.д.?
Понятно, что если будет надо, то сделаете. Больше интересует уже имеющийся опыт.
У нас всё плотно завязано с УТ11 и БП 3.0 в плане обменов из-за специфики организационной структуры - свой опт продает своей рознице и дюжина юриков на это всё.

Вот тут вопрос возник. Посмотрел пост на твоем форуме. Если рекомендуется ТиИ со всеми галочками для РИБа, то какая архитектура обменов?
В плане того, что всё со всеми обменивается регистраторами? Иначе проверка ссылочности сразу похерит кучу данных в РИБе, т.к., например, в типовой розница регистры, которые формирует отчет о розничных продажах, в РИБы рассылаются, а сам регистратор - нет. Ну и тоже самое с чеками в не закрытой смене, пока они регистры формируют.
Ну и там наверное еще примеров можно привести, это просто самое очевидное.
У нас в РИБах стандартное ТиИ это реиндексация таблиц и пересчет итогов. Логическую целостность и реструктуризацию таблиц пришлось использовать только раз, когда лечил NULL в таблицах.

Наверно, кроме количества узлов, надо указывать еще количество документов и общий размер базы данных. Одна сеть, с которой сейчас работаем, стала загибаться после 2 лет работы на УРБ (стандартная розница 8) уже при 8 магазинах. Со слов, перепроведение документов, если что-то правилось задним числом, занимало часы. В расчете себестоимости какие-то совсем непонятные значения были. Это на продуктовой рознице. База весила, насколько помню, порядка 10 гиг.
После этого они начали искать варианты спрыгнуть с решений на данном продукте.

FinSoft, типовая Розница 2.х не приспособлена для РИБов. Оно просто загибается на обменах и на росте размера баз. Даже правильнее так сказать - все типовые конфигурации на управляемых формах не предназначены для серьезного использования механики распределенных баз и ярче всего это видно как раз в розничной торговле. 1С эту историю забросила и развивает тонкие клиенты, Web и мобильные решения. Всё, что завязано на инет, а не на автономность.
Кто сидит на Розница 2 с РИБами все имеют полностью переписанные механизмы обменов и не только. И это только верхушка айсберга, т.к. хорошо бы иметь хоть по какому то вменяемому по железу "серверу" на каждый РИБ с SQL или другой субд, т.е. про файловый режим и работу на слабом железе лучше забыть)

У нас, например, за 2 года самые большие базы весят чуть меньше 2 гигов и расти не будут особо. Но это обычные формы и в целом довольно легкая конфигурация, которая нормально живёт в РИБах.
Ну и в 1С это плохая история с массовым перепроведением всего и вся, что участвует в обменах, за большие периоды времени. Всё равно что себе в ногу стрелять :) Процессы должны быть выстроены так, чтобы это не требовалось.