Если вы работаете с большим числом клиентов, то вам наверняка знаком вопрос «Кто из клиентов давно не приходил?».

Он настолько же типичен насколько типична и попытка ответить на него по-простому: а давайте найдем всех клиентов, которые ничего не покупали последние столько-то дней. В общем, не такой уж и плохой вариант и у него даже есть название — RFM-анализ, ну, точнее, это — часть RFM-анализа.

Однако, если клиентов много, а вы предлагаете некое разнообразие услуг и (или) товаров, то упомянутый подход будет весьма грубым. Почему? Потому что паттерны поведения разных клиентов отличаются. Соответственно, регулярность их взаимодействия с вами так же будет разной. Допустим, если вы продаете расходные материалы, то потребность различных покупателей в вашей продукции разнится в зависимости от интенсивности их деятельности. Да и при сопоставимой интенсивности стратегия закупки может отличаться, что сказывается на периодичности закупки. Те же соображения относятся и к услугам и к иным товарным категориям.

Добрый день. В открытом доступе наконец-то появился огромный справочник штрихкодов с наименованиями товаров, категориями и брендами.

Мы работаем над ним лет 8 и теперь в нем около 3 миллионов штрихкодов в стандартах EAN (EAN-13, EAN-8) и UPC (UPC-A, UPC-E).

Добрый день. Помнится, в одном сериале про заучек ребята рулили стерео-системой, находящейся в пределах доступности собственной руки, из компьютера, передавая сигнал посредством интернета через всю планету. Здравомыслящая девушка, которую они хотели удивить, впечатлена не была, ибо полагала, что обычный ПДУ дешевле и проще.


Тем не менее, есть хорошая новость: incredible machine все-таки может быть полезна. Например, для тестирования программных систем.

Добрый день

Автоматизация розничной торговли — весьма типичная задача, с которой сталкиваются в том или ином профиле разные люди разных специальностей. Соответственно, и большинство технических проблем, возникающих в контексте этой задачи проработано вполне основательно.

Тем не менее, мы решили взять на себя смелость рассмотреть вопрос концептуальной модели учета розничных продаж.

Основной предмет данной статьи — механизм трансформации первичных данных о продажах в учетные документы ERP-системы. Статья максимально абстрагируется от конкретных систем, реализующих описанные техники, но используемая терминология частично заимствована у open source ERP-системы OpenPapyrus (там же описанные подходы реализованы и превосходно работают на протяжении многих лет).

Несмотря на то, что я делаю ударение на рыночном сегменте розничных продаж, та же схема применима в равной степени к ресторанному бизнесу и, частично, к иным сегментам автоматизируемого бизнеса.

Добрый день.

Мы опубликовали систему управления предприятием Papyrus в исходных кодах под именем OpenPapyrus. Проект так же опубликован на сервере sourceforge.

Технические аспекты я распишу в отдельной статье, а здесь кратко расскажу о том, что такое OpenPapyrus и почему эта система стоит того, чтобы с ней ознакомиться и начать ее использовать.
OpenPapyrus — инфраструктурная система для управления бизнесом, над которой мы работаем более 20 лет (с 1996 года), развив в ней обширный функционал для управления бизнесом в широком наборе сегментов.

До текущего момента мы продавали систему Papyrus только как проприетарный продукт. В дальнейшем мы будем развивать одновременно оба продукта — проприетарный и открытый (тем более, что это — почти одно и то же).

Мы считаем (Open)Papyrus одной из лучших систем такого класса на российском рынке. Утверждение, конечно, сильное и субъективное, но теперь, когда все карты на столе все исходные коды в github'е, оно может быть проверено кем угодно.

Необходимость сложной обработки текстовых данных, хранящихся в ERP-системах (и не только) возникает достаточно часто. В качестве вводных примеров можно привести следующие:

• Унификация наименований товарной номенклатуры
• Автоматическая расстановка формализованных атрибутов товаров на основании их наименований или описаний
• Преобразование почтовых адресов как с целью унификации так и для формального структурирования
• Определение пола человека по его имени
• Извлечение информации из примечаний к документам (например, для автоматического связывания записи из выписки с отгрузочными документами)
• и т.д. (фантазировать можно еще долго)

Двадцать лет назад, когда начал работать с корпоративными системами, был немало раздосадован тем, что при получении отчетов постоянно приходится вводить полную дату начала и полную же дату окончания периода. С тех пор сменились поколения процессоров, операционных систем, и т.д., а большинство программ по-прежнему требуют от пользователя лишних пальцедвижений для ввода даты начала и даты конца периода.

В этой статье хочу поделиться классификацией схем промо-акций, автоматически обрабатываемых POS-системами, выстроенной на опыте разработки таковых для множества клиентов в течении многих же лет. Надеюсь, она будет полезна как разработчикам, реализующим сами POS-модули и интерфейсы с ними, так и пользователям таких систем.

Проблема отрицательных остатков в товарном учете часто возникает в сегментах розничной торговли, управления рестораном и производстве. В других сегментах бизнеса (скажем, оптовой торговле) эта проблема так же дает о себе знать, но, вероятно, в меньшей степени.

Суть проблемы состоит в том, что фактически продаваемая или расходуемая для производства товарная позиция может не присутствовать в достаточном количестве на учетном остатке. Далее это явление я буду именовать «учетный дефицит товара» или просто «дефицит». Полагаю, читатель хорошо знаком с причинами возникновения учетного дефицита, потому не стану вдаваться в их описание. Целью статьи является рассмотрение способов решения этой проблемы в программных системах автоматизации.