Бесплатная программа розничной торговли на SunFlurry. Презентация от разработчика. : Кассовые программы

Бинарные файлы состоят из клиента, сервера и программы для разработчиков (Студии). Сервер производит работу с базой данных (в данном случае ч/з SQLite, но также есть возможности подключения к другим СУБД, не в бесплатной разнице). Клиент работает только с подключением к серверу (tcp/ip). Клиент -- визуальная программа с которой работают операторы, в т.ч. на кассе. В общем-то стандартный подход. Сервер и много клиентов.

И я это самое тоже имел в виду. Обработки переноса остатков и документов в базе есть, они взяты из "старших" баз производства и опта, где я обычно осуществляю обрезание базы, скажет в мае, когда бух. год закрыт, путем переноса остатков на начало года и документов с начала года по май месяц. Если бухгалтерам необходимо изменить прошлый год, они эти делают в старой базе (для формирования отчетности) и вводят документ корректировки в новой базе за, скажем, 31.12.XXXX -- для сохранения сальдо.

Да, я знаю это, спасибо. Эти параметры доступны в ini-файле сервера, называются SQLiteSynchronousWriting (по умолчанию 2), и JournalMode (по умолчанию WAL). Конечно, можно временно отключить синхронизацию, загрузить Kladr и включить, но в реальной работе это недопустимо, так как параметр 0 (OFF) гарантированно испортит в какой-то мере базу данных при пропадании питания без корректного завершения. К тому же в этом нет необходимости, SQLite достаточно быстро сохраняет документы, пусть в 4 раза медленнее, чем MS SQL, но скорость достаточно высока, чтобы кассиры благодарили за переход с 1С:Розница (как они говорят -- наши мужики-алкоголики говорят спасибо, что не нужно долго стоять в очереди).

То есть некая разновидность ip сервера. А коннект постоянный нужен к серверу или магазины могут работать в автономном режиме с последующей синхронизацией?
Что-то не очень понятно со срезом. Получается не удаление старых данных, а создание новой базы с заливкой туда документов рабочего периода? Обычно без среза держат не последние несколько месяцев, а несколько лет, а бухгалтерская база отдельно от оперативной. В бухгалтерии много условностей, зачастую запутывающих оперативный учет.

Магазины работают с базой данных посредством сервера. Для обычного случая: одна касса и один компьютер заведующей -- сервер (и БД) находится, к примеру, на кассовом компьютере, там же стоит программа-клиент, которая работает в кассовом режиме. Вторая программа-клиент стоит на компьютере заведующей, которая принимает товар. Это локальная база магазина, и, так как она бесплатная и очень маленькая (обычно у нас базы в пределах 20-50Мб), нет смысла держать ее в удаленке или где-то еще. Один магазин, одна база и обмен с ЦБ.

Можно сделать и одну удаленную базу на несколько магазинов, к примеру, через подключение TCP/IP (кассы и терминал не очень дружат). В таком режиме работа будет медленнее, но скорость вполне терпимая. Но какой смысл, если локальную базу так легко установить и она не требует сильной машины?

У нас в опте и пр-ве бухгалтерский учет ведется в рабочей базе. Бух. учет -- это один из самых простых узлов (по моему скромному мнению). Отчеты, которыми пользуется бухгалтерия, не менялись с 60-х годов и раньше. Новый план счетов уже существует 20 лет (не ловите на слове, не захотел проверить). Никаких условностей, все очень просто. Зато никакого доп. обмена, одна база на сервере, а не две, и очень много других плюсов.

Наши старые базы обычно содержат от 3 до 7 лет полезной информации. Новая база создается с нуля, в нее переносятся справочники, остатки и некоторое кол-во документов. Бухгалтерию это не напрягает, так как год уже закрыт и что-то менять в старой базе обычно нет смысла. Новая база в таком виде очень маленькая и быстрая. Удалять что-то из базы для ее обрезания я бы не стал, это гораздо более длительный и трудоемкий способ. И никто не может работать, когда это происходит. Я начинаю переносить справочники и документы в понедельник (к примеру), по мере перенесения закрываю дату запрета, люди продолжают работать. В среду утром уже есть новая и старая базы, и люди работают в новой. Никакого стресса. С учетом большого документооборота (до 4 т. документов в день в некоторых филиалах), это достаточно быстро.

А пользователи у центральной базы, кроме бухгалтерии, есть? Менеджеры, экономисты и т.п.? У них потребности обычно несколько иные. Например, если надо проанализировать что-то за несколько месяцев, а часть информации уже срезана, открываете старые базы и формируете общий отчет? Или, к примеру, в оптовке покупатель вернул товары, которые ему отгружали в старом периоде, как проверить, брал он эти товары, когда, по каким ценам? Или в бухгалтерии возврат оформляется обратной реализацией с ценами продажи, а менеджерам нужно на остатках видеть реальные закупочные цены.
Таких вопросов много на практике возникает. Не знаю, стоит ли продолжать, у меня общее впечатление уже сложилось. Единственный момент хотел уточнить, если не затруднит, что производится (торгуется, это важно для понимания функциональности), какое примерно количество номенклатурных позиций в самой нагруженной базе, какое среднее количество строк в чеках (отгрузочных накладных).

Сейчас запустил код загрузки кладра в своей системе и прошло уже 40 минут и оно всё загружается. На работе у меня SSD может в этом всё дело. И да, мы пишем напрямую в базу insert into и нет никаких связей, так что должно работать мухой, но по факту да, думаю что будет загружать около 60 минут. По поводу разделения - у нас каждый месяц физически расположен в новой базе, например, апрель расположен в файле ДАННЫЕ0422 это очень не удобно при программировании, но зато база не растёт и не надо её резать

Ниже привёл код загрузки на нашем интерпретаторе. Интерпретатор мы украли и допилили, он написан на delphi

Я в свое время тоже думал над разделением базы данных. У меня стандартно топспид, каждая таблица в отдельном файле. Сильно растут только отдельные таблицы. В моем случае это таблица строк товарных документов и таблица чеков. Подглядел в одном старом приложении на акцессе идею, которая понравилась. Вместо дробления по периодам была сделана вторая архивная таблица. Данные из рабочей можно периодически переливать в архивную, а отчеты строятся по обоим. Архивная таблица только на чтение, но при потребности можно вернуть документы обратно в оперативную. Программирование немного усложняется, но остается в стандартной парадигме. Так как большая часть данных находится в файлах только на чтение, повышается надежность и скорость работы. Соответсвенно, срезать базу данных можно редко или совсем не срезать, по желанию.
Когда всплыл вопрос, что у одного из пользователей рост базы данных стал очень интенсивный, нашелся вариант использования actian zen (btrieve). Переделывать ничего практически не пришлось, программа автоматически при запуске определяет тип используемой базы данных, прикладной код идентичный. В условиях сети супермаркетов получается центральная база данных на сервере actian zen, а в магазинах локальные базы файловые.

Центральная база в основном для финансовых менеджеров, БДР, ББЛ, БДДС и остальные аббревиатурные столбцы цифр. Бухгалтеры ее используют, но в меньшей степени. ЦБ обычно имеет несколько лет, если этого не хватает, можно зайти в старую базу. Теоретически я мог бы войти в старую базы программно и добавить ее цифры к общему отчету "на лету", но это насколько глупо, что я никогда в здравом уме этого бы не сделал. Финансисты/экономисты должны это делать сами. Им платят деньги за что-то большее, чем нажатие на "сформировать".

Весь этот разговор, хоть в целом и интересен, несколько не относится к теме бесплатной розницы (хоть она и работает под управлением той же системы). Думаю, я не буду углубляться в наши основные бизнесы (нет особого смысла, наверное). Нейтральная информация: номенклатуры достаточно много за годы набралось (до 50 т. позиций в опте и 20 т. в пр-ве (промежуточные детали пр-ва добавляют много)), после обрезания базы я физически удаляю некоторые элементы, но количество обычно увеличивается быстрее, чем происходит убытие; это нудная работа, чистить базу после обрезания, но ее нужно делать, к сожалению.

Главное преимущество локальных баз на SQLite3, это то, что база растет очень медленно. По крайней мере в два раза медленнее, чем MS SQL или Postgres. Кроме того, как я уже говорил выше по тексту, в проекте имеется встроенная возможность обрезания базы, которую мы используем в других бизнесах много лет, и процесс достаточно простой.

Мы выпустили новый релиз проекта, основные изменения:
* Добавлена простая обработка загрузки остатков из 1С:Розница, также можно скачать простую обработку для выгрузки из 1С (см. статью Установка проекта Розница).
* Добавлена загрузка Фронтол (для связки SunFlurry - SunFlurry по протоколу Фронтол), раньше программа только выгружала данные.
* Исправлены ошибки, сделаны улучшения при отказах выгрузки марок в ЕГАИС (выводится таблица товаров с марками с возможностью удалить товар из таблицы, если его марка не выгружается в ЕГАИС), сделаны другие мелкие изменения.

На сайте (см. статью Установка проекта Розница) появился краткий список возможных простых вопросов по проекту, частично, чтобы показать, что работать с ним не сложно. В списке, к примеру, рассмотрены такие вопросы, как "как задать цены на товары", "настройка сканера", "добавление банковского терминала", "анализ продаж", "остатки", "инвентаризация в магазине", "принятие поступления в ЕГАИС", "сравнение остатков с ЕГАИС" и др. Ответы изложены в очень краткой форме, для быстрого руководства.

Также на сайте (см. статью Установка проекта Розница) добавлено краткое руководство для настройки обмена по протоколу Фронтол.

Планируется добавление стандартного протокола обмена 1С Enterprise Data для большей гибкости в обмене с разными системами.