Учет в общественном питании.

Вот решил попробывать автоматизировать учет в общественном питании. За основу решил взять вторую версию ядра. Думаю сначала правильно создать первичные документы, а потом логику их обработки. Кто нибудь делал такое? С какими трудностями мне придется столкнуться? Или мне повезет и все пойдет как по маслу? :) Думаю сюда выкладывать свои успехи и неудачи :)

P.S. Признаюсь я пока не до конца понял как все функционирует, пытался разобраться с ОпТорг, но как-то все там запутанно, а хорошей документации к сожалению нету :(

Forums: 

Re: Учет в общественном питании.

Думаю сначала правильно создать первичные документы, а потом логику их обработки. Кто нибудь делал такое?

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

С какими трудностями мне придется столкнуться? Или мне повезет и все пойдет как по маслу? :)

Если завтра выиграешь в лотерею миллион, то ВСЕ пойдет как по маслу.
Многое зависит от твоего опыта проектирования систем c применением ООП.
Мой совет: не городи развесистые иерархии классов.

Думаю сюда выкладывать свои успехи и неудачи :)

Welcome :-)

P.S. Признаюсь я пока не до конца понял как все функционирует, пытался разобраться с ОпТорг, но как-то все там запутанно, а хорошей документации к сожалению нету :(

Спрашивай здесь. Постарюсь помочь, остальные тоже в стороне не останутся.

Трудность 1:установка ядра п

Трудность 1:
установка ядра прошла успешно. скачал проводник версии 2.0 и попытался подключиться к базе. Подключение к базе прошло нормально, но при попытке открыть пользовательский корень "Личная: Supervisor"? вылетает ошибка Violation of PRIMARY KEY constraint 'PK_Tree'. Cannot insert duplicate key in object 'Tree'.
Кто-то знает в чем может быть причина?

MSSQL с сервис паком 4,грохн

MSSQL с сервис паком 4,
грохнул индекс PK_TREE, таблица TREE заполнилась, правда там все в двойном экземпляре, ща попробую разобраться с процедурой FillTree, по идеи она заполняет таблицу :)

во время раскопок нашел следующее:
код в процедурах, который реализует события продублирован,
вот пример

create procedure Sfolder$fill$post @p1 int, @p2 int, @p3 int as declare @ret int
set @ret=NULL exec @ret=Doc_fill_key_ @p1, @p2, @p3 if @ret<>0 or @ret is NULL return 1
set @ret=NULL exec @ret=Doc_fill_key_ @p1, @p2, @p3 if @ret<>0 or @ret is NULL return 1
set @ret=NULL exec @ret=Enlisted_fill_tree_ @p1, @p2, @p3 if @ret<>0 or @ret is NULL return 1
set @ret=NULL exec @ret=Enlisted_fill_tree_ @p1, @p2, @p3 if @ret<>0 or @ret is NULL return 1
GO
 
create procedure Sfolder$put$edit$ @p1 int, @p2 int, @p3 int 
as 
declare @ret int 
set @ret=NULL exec @ret=Folder_put_edit_ @p1, @p2, @p3 if @ret<>0 or @ret is NULL return 1 
set @ret=NULL exec @ret=Folder_put_edit_ @p1, @p2, @p3 if @ret<>0 or @ret is NULL return 1
GO
 

и так везде, покрайней мере те процедуры, что я пересмотрел такие,
есть у кого-то какие то идеи почему так произошло?

Вообщем, переставил ядро еще раз и все стало нормально. Я сервис пак поставил после того как установил ядро, наверно, в этом и была проблема, хотя странная она какая-то :roll:

Изображение пользователя st.

Совершенно верно, проблема с с

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

Просматривал ОпТорг, по сути т

Просматривал ОпТорг, по сути там большая часть того, что мне нужно уже реализовано. С одной стороны, если попробывать использовать наработки того, что сделано в ОпТорг, то процесс разработки упроститься, хотя с другой на "разбор полетов" тоже время нужно. С нуля писать тоже не так просто, я даже не знаю с какой стороны подступиться к Nexus, вроде все просто, но в то же время все сложно :) Попробую второй путь ;)
Для начала попробую сделать класс "Товар", "Товар" будет абстрактным классом. На основе "Товара" создам классы "Полуфабрикат" и "Блюдо".
На этом пока все, буду дальше думать ;)

Изображение пользователя ipanshin.

Скоро появится

Скоро появится еще одно ядро (как я понимаю). Скажем SkyMind.

Опторг надо брать только в качестве примера. Писать надо свое. Иначе будешь исправлять старую логику, которая в некоторых местах очень даже сыровата. Логика продавцов, мыслящих в штуках. IMHO общепит, это прежде всего единицы измерения, рецептура, ну и ессно вкусный запах. А как раз это и не реализовано.

О первичке. Храню первичку (о новой купленной технике) в отсканированных файлах в БД. Более всего важна поисковая система, которую строю на классах иерархий.

Все, что перечислил относится к NexusMind и в опторге реализовано в зачаточном состоянии.

Трудность первая: Начать работать и работу довести до конца. Понимание придет.

Вторая трудность: в процессе работы придется модифицировать клиента, так как он тоже сырой. У меня версия 2.52. Исходная насколько помню 2.47.

Успехов
С уважением
Игорь

Боты

В прихожей знакомая пара одна
Черные, пыльные БОТЫ.
Цвета простого загара она
И непомерной Работы.

Без алгоритмов живет страна
Семейным ритмом, привычным до рвоты,
У, БОТ носящих, забота одна:
Копать от забора и до субботы.

Общество, питающееся
своими членами,
Аморально.
Я не член его ...
Я- НЕРВ. Оголенный...
Натурально.

09.12.2005

Изображение пользователя st.

В общем случае писать "с нуля

В общем случае писать "с нуля" не нужно (иначе теряется смысл базовой версии), но в данном конкретном я поддержу Игоря, поскольку версия ОпТорга для ядра 2.0 не готова.
Для снижения рисков имеет смысл начинать делать прототип на ядре, используя старый ОпТорг в качестве примера.

в процессе работы

в процессе работы придется модифицировать клиента, так как он тоже сырой.

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

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

Изображение пользователя ipanshin.

чтобы документ мож

чтобы документ можно было перемещать, но в каких то пределах

Идеологически, да и по всякому неверно. Документы и прочие объекты никуда и никогда не перемещаются. Над всем этим строится нужного типа иерархия, которая дает нужное расположение объектов в соответствии с деревом в левой панели эксплорера и настройки пользовательского фильтра.
скажем
БЕЗАЛКОГОЛЬНЫЕ НАПИТКИ, по дате прихода, по типу, по отделам, по поставщикам, по алфавиту. Ну и т.д.

Идеологически, да

Идеологически, да и по всякому неверно. Документы и прочие объекты никуда и никогда не перемещаются.

Идеологически, может и не верно, но по моему мнению не надо пользователя ограничивать. Захотела тетя Дуся в папке АЛКОГОЛЬНЫЕ НАПТИТКИ, вместо папки ВОДКА создать папку ВОДКА 40 градусов и ВОДКА 50 градусов, взяла и раскидала документы по папкам, этот пример надуманный, но я думаю такое вполне реально. Да и вдруг человек ошибся при создании документа и вместо папки РОМ отослал ее в папку там ДЖИН ;) Я согласен что неплохо было бы чтобы это система контролировала что и куда сохранялось, но это просто нереально все предусмотреть.

Я тут посмотрел список событий, нашел события move, я так думаю надо для Папки создать метод, который бы сообщал примет она документ или нет. Допустим назовем его "Можно_к_вам?" и при событии move товара вызывать метод "Можно_к_вам?" папки куда мы перемещаем товар.
Правда, я что-то не нашел как вызывать метод для какого-то класса?
Такое возможно? Или просто вызвать процедуру соответствующую данному методу?

Изображение пользователя st.

а сейчас вопрос по

а сейчас вопрос по системе, можно ли ограничить документ в пределах какой то папки?

Написать свой обработчик события move для этого класса :)

Изображение пользователя ipanshin.

Я не знаю возможностей данного

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

Вторым шагом надо взять СР и адаптировать его под новое ядро или написать свои классы объектов. Это не так сложно, если воспользоваться автогенерацией классов, ктр тоже уже написано.

Хочу сразу сказать, что это не бесплатное решение.
Но оно много съэкономит и сил и времени.

Я тут посмотрел сп

Я тут посмотрел список событий, нашел события move, я так думаю надо для Папки создать метод, который бы сообщал примет она документ или нет. Допустим назовем его "Можно_к_вам?" и при событии move товара вызывать метод "Можно_к_вам?" папки куда мы перемещаем товар.
Правда, я что-то не нашел как вызывать метод для какого-то класса?
Такое возможно? Или просто вызвать процедуру соответствующую данному методу?

События для папки, когда в нее перемещается объект не предусмотрено. Поэтому правильнее написать обработчик для события move у документа, который и будет определять можно переместить объект или нет.
Для папки я бы создал метод "Что в ней может быть?" и через обработчик этого метода edit задвал бы какие виды продуктов могут содержаться в этой папке. Но для этого надо на "Товаре" ввести атрибут "Вид продукта".

Еще хочу добавить, что данная задача, по-моему, нацелена на обеспечение некоторой дисциплины расположения объектов в дереве классификации.
Есть дополнительный модуль "Иерархии", написанный Дмитрием Цурановым, который позволяет строить динамические иерархии на основании артибутов объектов. ОЧень удобно для построения иерархических справочников. Рекомендую с ним связаться (Dmitry.Tsuranov@TraceOne.fr).

Я не знаю возможно

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

А чем отличаются возможности ядра NexusMind от стандартного?

По сути это ни коммерческий проект, это просто мое желание применить Nexus под задачу, которую уже реализовали, правда чуток коряво и другими средствами (Delphi+MSSQL) Хочется пощупать возможности Nexus на том, с чем я уже сталкивался.

П,С
У меня появилась дикая идея. А что если, попробывать реализовать клиент под Web? Тогда возожности еще больше расширяются :)

Изображение пользователя ipanshin.

А чем отличаются в

А чем отличаются возможности ядра NexusMind от стандартного?

Полного списка отличий нет. Но м.б. я его сделаю, если устрою показ для разработчиков СР и мы их определим, как ключевые.
Здесь важно понять на самом деле другое. Ведь на моем ядре базируются такие классы как код, автогенерация, иерархии, ... Плюс к этому работает во многом уже исправленный С++ клиент.

А что если, попробывать реализовать клиент под Web?

Why not? Я вижу еще один путь. Просто синхронно публиковать документы на сайте параллельно с созданием их в БД. Я это делал. Остальное все работает в режиме просмотра. Важна в этом вопросе цель.