На главную страницу Версия-Т
VTSoft.ru

Интерфейс Online Server

RSS
Интерфейс Online Server
 
#1
24.12.2002 18:33:40
Знаю, что ведётся доработка Online Server.
Поэтому хочу напомнить о некоторых проблемах, которые возникают при работе с ним:

Как известно, у вас так и не решена проблема повторяющихся папок.
Во-первых, при считывании базы товаров в другую программу нельзя считать содержимое второй папки, так как папка в функциях задаётся именем.
Во-вторых, имел место печальный случай: Клиент взял на работу нового сотрудника, а тот видя, что экран Online Serverа мало отличается от Explorerа пытается создать в дереве папку. Для этого он выделяет папку, в которую хочет поместить вложенную и добавляет папку. Каково же его удивление, когда папка появляется в папке, которая была открыта (программа в отличие от Explorerа не поменяла активную папку перед созданием вложенной). После чего человек пытается удалить папку и надимает delete. К сожалению, корневой раздел товаров имел имя "новый раздел" как и вновь созданная папка. Естественно, что программа в мгновение ока удалила всю базу.
(Конечно, потом просто был выгружен сервер и заново посторено дерево в файле tree.dat, а файлы base*.dat остались без изменения).

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

И основной вопрос - почему формат базы товаров не DBF?
 
 
 
#2
25.12.2002 07:34:34
Цитата
Torquader писал(а):
Как известно, у вас так и не решена проблема повторяющихся папок.
Во-первых, при считывании базы товаров в другую программу нельзя считать содержимое второй папки, так как папка в функциях задаётся именем.

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

Цитата
Torquader писал(а):
Но, хотелось бы, чтобы будущая версия была более продумана по части стандартных денйствий. То есть, если уж делается похожей на Windows и использует стандартные действия, то результат должен быть таким же как и у других программ. Потому как чайников обучают именно стандартным действиям.
Ну или хотя бы сделать более удобный редактор базы, даже если он будет запускаться отдельно.

Постараемся сделать "стандартные действия" максимально совпадающими с аналогичными в других программах. :)

Цитата
Torquader писал(а):
И основной вопрос - почему формат базы товаров не DBF?

На данный момент для основной базы используется свой формат, который обеспечивает более высокое быстродействие по сравнению с DBF. В момент работы вся база хранится в ОЗУ (на диск сбрасываются только изменения), что позволяет увеличить скорость поиска товара при запросе от ККМ и т.д., но накладывает повышенные требования к объему оперативной памяти (хотя это критично только в случае хранения в базе чеков за несколько десятков смен по нескольким ККМ). OnlineServer v 2.0 в качестве DB Engine будет использовать SQL сервер Firebird, что позволит работать нескольким серверам в сети с одной базой, полностью отвязать отчеты от реализации программных модулей, и т.д. Работа с данными будет возможна посредством новой реализации OLE, импорта/экспорта в текстовые файла и файлы DBF, а также при помощи непосредственного подключения к БД (чтение данных ни к чему не обязывает, а при изменении данных с использованием непосредственного подключения к БД ответственность за целостность и корректность данных будет лежать на разработчике, использующем этот метод работы с базой данных).
 
 
 
#3
25.12.2002 09:25:33
Вопрос вот какого плана: В версии онлайн-сервера 2.0 сервер Файрберд будет использоваться как более надежное жранилище данных, а вся логика будет "зашита" в .ехе файл (типа 1С SQL-версия), или же Вы реализовываете клиент-серверную реализацию, где .ехе вызвал действие, отработала хранимая процедура сервера и .ехе получил ответ либо результат ?
 
 
 
#4
25.12.2002 11:24:42
Вычитывание данных производится запросами из приложения (за исключением редких случаев), а изменение данных, преимущественно (но не полностью), производится при помощи хранимых процедур.

:?: А это имеет какое-либо принципиальное значение?
 
 
 
#5
26.12.2002 07:22:01
В нормальных условиях наверное всеравно, но ведь у нас как всегда... Предположим ОС "зависла", и затем последовала холодная перезагрузка системы и т.д. Просто нормальный SQL сервер незавершенные транзакции откатит и логическая целостность информации должна прийти в норму. Хотя помоему основная задача по максимуму снизить вероятность рассогласования между З-отчетом кассы и таблицей продаж сервера, причем при условии что связь между ккм и компьютером периодически пропадает, на сигналы действуют помехи и т.д. Я сам просидел 6+6+5 часов за кассой со сканером, и с 400 чеков один потерялся, то есть чек набрался, напечатался, попал в З-отчет, а онлайн-сервер 1.46 показывает мне текущий чек, то есть до него не дошло, что чек напечатали уже и касса давай закорюли показывать и разные символы печатать, пришлось выключить и включить. Короче продажа в компьютер не попала.
 
 
 
#6
26.12.2002 09:08:57
Цитата
ping писал(а):
В нормальных условиях наверное всеравно, но ведь у нас как всегда... Предположим ОС "зависла", и затем последовала холодная перезагрузка системы и т.д. Просто нормальный SQL сервер незавершенные транзакции откатит и логическая целостность информации должна прийти в норму. Хотя помоему основная задача по максимуму снизить вероятность рассогласования между З-отчетом кассы и таблицей продаж сервера, причем при условии что связь между ккм и компьютером периодически пропадает, на сигналы действуют помехи и т.д.

Действительно, при обрыве коннекта с клиентом (или в другой нештатной ситуации) сервер откатывает все незавершенные этим клиентом транзакции. Время выполнения простых типовых операций на сервере не сильно различается при выполнении их с клиента и при вызове с клиента ХП, которая производит те же действия. А поскольку управление транзакциями в Interbase/Firebird производится только с клиента, то необходимость реализации хранимых процедур, определяется только требованиями к целостности данных (при их изменении) и необходимостью формировать сложные запросы, которые при помощи стандарта SQL реализовать проблематично или их быстродействие "оставляет желать лучшего". Но это лирическое отступление, а вообще я особых проблем не вижу: при запросе от ККМ покупка сразу сохраняется в БД вместе с информацией о ККМ, номере КЛ и номере чека, к которым она относится. Операция выполняется в короткой транзакции. Даже если сервер из-за помех на линии (или по другой причине) не отловит событие закрытия чека (с АМС-200Ф маловероятно, с АМС-100Ф такая вероятность побольше), то при начале набора на данной ККМ следуещего чека, текущий чек попадет в закрытые (или сброшенные) чеки автоматически.

Цитата
ping писал(а):
...и касса давай закорюли показывать и разные символы печатать, пришлось выключить и включить. Короче продажа в компьютер не попала.

Немного непонятно про закорюли... Если происходят сбои в ККМ, то они и являются причиной потери чеков в БД, и решать эту проблему в товароучетном ПО не совсем правильно (точнее, полностью порешать эту проблему на верхнем уровне не получится). Нормальное функционирование системы возможно, как минимум, только при нормальном функционировании каждой его составляющей.
 
 
 
#7
26.12.2002 10:28:53
Цитата
Eugene писал(а):
...Операция выполняется в короткой транзакции. Даже если сервер из-за помех на линии (или по другой причине) не отловит событие закрытия чека (с АМС-200Ф маловероятно, с АМС-100Ф такая вероятность побольше), то при начале набора на данной ККМ следуещего чека, текущий чек попадет в закрытые (или сброшенные) чеки автоматически."

Вот здесь и возникает развилка - сервер "не знает" точно что с текущим чеком делать - то ли он попал в фискальную память кассы , то ли нет. И возникает несоответствие между З-отчетом и таблицей продаж сервера, то есть или штатная единица в организации должна периодически руками и головой исправлять данную ситуацию, выражая эмоции, либо можно сказать что система в целом и на практике не достаточна надежна, что приводит к такому - при инвентаризации была выявлена недостача, вроде с кассиров надо бы удержать, а кассиры это хакеры старые, палец в рот не клади - с их слов компьютер с кассами зависал - вот и потери...
 
 
 
#8
26.12.2002 12:04:26
Не совсем так...
В версии сервера 2.0 при возникновении подобных ситуаций будет производится сверка с электронным журналом кассового аппарата, и на основе нее будет приниматься решение о том закрывать или сбрасывать текущий чек. Само собой разумеется, если произошел сбой на ККМ, то 100% гарантию того, что текущий чек попадет туда, куда должен, даже сверка с ЭЖ дать не может (поскольку неизвестны последствия сбоя для ККМ). И конечно этот алгоритм не поможет в том случае, если выдернуть из ККМ кабель и вести продажи свободными суммами. Здесь о корректном товарном учете, понятно, не может быть и речи.
 
 
 
#9
26.12.2002 23:39:27
Чек пишется только во flash, из которой он может быть считан сервером. Конечно, если набрать товар на клавиатуре ККМ с количеством, и он будет считан с сервера, а потом отсоединить кабель и пробить такую же свободную сумму, то она будет воспринята как считанный с сервера товар ...
конечно, если кто-то сможет сбросить признак не подключая ККМ к серверу E-УЧ и снять Z-отчёт, то некоторые чеки могут потеряться, но для того Е-УЧ и придумано, чтобы этого сделать было нельзя.
 
 
 
#10
27.12.2002 04:23:19
Ok, т.к. технически 100% восстановить после сбоя соответствие между ФП кассы и ТаблицейПродаж (ТП) сервера нет возможности, то требуется вмешательство человека. Оно может быть в 2х вариантах: 1) После закрытия смены на кассе человек сверяет контрольную ленту с кассы с ТП сервера, зная что сбой был в 11:30. Обнаружив отсутствующий чек в ТП сервера он пытается найти его с списке сброшенных чеков и если находит, то должен каким-либо образом подправить ТП. СтрЁмно. 2) В момент сбоя - перегружают сервер, выключают и включают кассы, сервер пытается восстановить соответствие между ФП кассы и ТП сервера и если не смог что-то определить пусть спросит у кассира, а кассир в этот момент имеет Х-отчет и видит ТП сервера, сверяет соответствие по последнему чеку, сценарий корректировки жестко ведется сервером и все ОК. Реален ли второй вариант, или есть еще какие-то факторы ? Р.S. для варианта торговли без свободных сумм, при исправной технике.