Форум

Проверил на 2 аппаратах - результат тот же.

поставиль драйвер
подключил свой Гепард НТС-МФ
в программе выбрал Меркурий МС-К (Гепард)
настроил порт 1 и скорость 9600 (как и ФР)

При запуске режима кассир ввод пароля доступа 0000
Сообщение красного цвета:
нет ошибки
код ошибки: 0
дополнительный код ошибки: 0
docstatus: 0
currentoper: 0

и в режим регистрации не пускает.

как добавить скрин? jpg и png не пускает.

скачал.

Цитата
Алексей Новиков пишет: Проблем особых нет. Зациклите получение нового номера условием уникальности. И делов-то.

так вот.
1. создаю док из харбора (newnumdoc()) - получаю номер 000001
2. создаю док из харбора (newnumdoc()) - получаю номер 000002
3. создаю док из харбора (newnumdoc()) - получаю номер 000003
4. создаю ШТАТНЫМИ СРЕДСТВАМИ БЕСТА - получаю номер 000004 (отлично)
5. создаю док из харбора (newnumdoc()) - получаю номер 000004 (ваще пипец)

Цитата
Но не забудьте предусмотреть выход из ситуации "неинкрементируемого номера". Например, номер, следующий за номером "бух/сп" будет тоже "бух/сп". Цикл может подвиснуть. Поэтому проверяйте свежесгенерированное и предыдущее значение номера документа. При их совпадении, отправляйте алгоритм по "чистой" ветви, например, предложив системе в качестве очередного номера "000001".

если чесно нет возможности так долго копаться в нумерации, тк предвижу еще проблемы при записи в Mdocm и mdoc. Поэтому продажи скину report.dbf и цепану его "как обычно". Если есть у ВАс возможность скинуть пример кода на нумерацию , буду очень благодарен.

Наткнулся я на те же грабли что и здесь
http://www.bestnet.ru/club/phpBB/viewtopic.php?t=8079&postdays=0&postorder=asc&highlight=newnumdoc&&start=30

то есть функция newnumdoc() опирается на увеличивающийся счетчик Nom_doc в поле memdat->ident1 (Алексей Новиков). При создании документа штатными средствами бест этот факт в упор не видит. И хз на каком основании нумерует документ. В итоге нумера пересекаются. Последствия известны. Речь идет об учете продаж в Торговом зале.

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

хорошие новости!

галка "Запускать как сервис" убрана и неактивна.
Да кста, запуская с RDP c правами админа. Может в этом проблема?
Хотя собственно какая разница. Локально или РДП - права то все равно админские

Цитата

FUNCTION NewNumDoc(cSclad,cVid,cType,cCodeDoc) //----------------------------------------------------------------------------// // Генерация уникального номера документа LOCAL cNumDoc MDOC->(dbPush(),SetScope()) cNumDoc := MDOC->(NWDOC("NUMDOC",UPPER(cSclad+cVid+cType+cCodeDoc),"NOM_DOC","MDOC")) // Проверка на уникальность IF !MDOC->(NVDOC(S_LIB_ADD,,"NUMDOC",UPPER(cSclad+cVid+cType+cCodeDoc),"NOM_DOC","MDOC",.T.,,{|x| IF(x != NIL,cNumDoc := x,cNumDoc) },.T.)) // Сброс счетчика NControlMem(UPPER(cSclad+cVid+cType+pCodeDoc1),"NOM_DOC",,.T.) // Теперь уж точно уникальный номер cNumDoc := MDOC>(NWDOC("NUMDOC",UPPER(cSclad+cVid+cType+cCodeDoc),"NOM_DOC","MDOC")) ENDIF MDOC->(dbPop()) RETURN cNumDoc

создаю новый документ на харборе путем записи в базу, для номера использую эту функцию, но как я понял кроме mdocm и mdoc еще гдето происходит регистрация НОМЕРА документа. Не подскажете где?

спасибо. так и сделал

после неудачной, как я понял установки пакета сп 1-9, выдает "Нарушено соответствие клиентской части и сервера приложний. Вход в систему невозможен"

И как теперь быть?

Пишу выгрузку справочника товаров в другую систему.
При переборке товара охота выводить полоску прогресса наподобии той что в БЭСТ
В справочники пользователя ничего похожего не нашел, хотя точно помнью что где-то видел. Спасибо! (БЭСТ4+ 12.01 (47)

foxpro 2.6 пишет в main.dbf уже года 3, проблем с индексами нет. Также нет проблем и с analit.dbf. А вот doc51.dbf и складские базы сопротивляются пока. Приходится искать другие подходы.

Цитата
nordk пишет: По Гепарду еще очень актуальна характеристика - номер поколения. Принцип поколений 3,7 и 9 по формированию чеков отличается от других. У нас кассовый аппарат 7 поколения, так что мы сейчас можем реально оттестировать чек для 3,7 и 9 поколения.

Речь идет о последнем поколении, конечно. Уточню этот момент в сервисе. По поводу принципа (основного) формирования чеков. Чек записываться в буфер и лишь затем выводиться на печать, - это главное отличие последнего поколения. За счет этого снижается скорость печати чека, точнее, скорость начала печати. Но уж если начал печатать то выводит его быстрее любого другого ФР. Собственно, высокая скорость печати и есть основное преимущество этих ФР-ов. Завтра опубликую то, что мой ФР выводит в Инфо. И мы может сравнить одинаковые ли у нас аппараты.

Цитата
nordk пишет: В данный момент идет работа с Меркурий MS-K версии 1 на драйвере Инкотекса версии 1.7 Хотите участвовать в тестировании ?

однозначно, да. Аппарат у меня есть (Гепард НТС МФ). КМП+ с ключем тоже имеется.
Жду указаний.

Цитата
nordk пишет: Для формирования накладных в БЭСТ специально созданы объекты, позволяющие это делать, чтобы Вы не пытались их формировать сами.

Речь идет о 4+ или о 5-ой версии?

пишу в шаблоне

^ESC t 17 // select character code tabel (17 - PC866 (CYRillic #2)
^GS h 100 // select bar code height - 100
^GS H 2,50 // select printing position for HRI characters 2,50(bellow the barcode)
^GS k 43 ############## NULL // print bar code

В итоге печатает
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?
С?С?С?С?С?С?С?С?С?С?С?С?.

Порт установлен переключателями 9600
Порт в системе тоже 9600
Что не так делаю?

В связи с тем, что есть лишь небольшой опыт на Харборе, ограниченный лишь рассмотреением и применением с небольшими изменениями готовых решений, публикуемых на данном форуме, хотел бы написать доработку (переоценка товаров (Беларусь)) на Foxpro. Доработка будет заключать в выборе товаров, проставлении количества, новых цен, затем формирование приходных и расходных документов по партиям. Это позволит просто, частично или полностью переценивать товар. Будут задействованы базы предположительно Mdocm, mdoc, spr_part. На Фокспро имеется твердые навыки как программирования так и разработки интерфеса. Но заметил за базами бэста следующую особенность. Запись в базу не приводит иногда к обновлению индексного файла и как следствие нужно делать переиндексацию. Кто-нибудь может прокоментировать это?

Цитата
nordk пишет: В течении следующей недели можем осуществить подключение КПМ к гепарду. Кассовый аппарат у нас есть.

насколько серьезны Ваши намерения?

Полностью с Вам согласен, но в этом месте не могли бы поподробнее
Где именно скрыты открытые возможности программмирования?

Цитата
Евгений Плешивцев пишет: но открыты возможности программирования, с помощью которых можно преобразовать формат Атола в приемлемый для БЭСТ.

Цитата
nordk пишет: Да давайте сначала поймем - как загрузить в БЭСТ !!! Если вы сделаете 2 разные операции, то у Вас будет 2 документа !!! и там и там будет 1 штука и с остатка спишется 2 телевизора !!!! А Вам нужно списать один.

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

в другом. Я бы обьединил эти документы т.к. необходимости в них нету. Товаро-учетной проге пофиг как продан товар. Важно получить оплаты с атола, но похоже атол оплаты не выгружает, а КПМ?

Раздел 1. Введение
Ситуация следующая: Имеем атол на кассе, который добросовестно продает товар. Все бы ничего если бы не смешанные продажи, т.е когда телевизор, скажем, продается частично за нал, частично по карте. Атол опять же добросоветстно в Z-отчете разносит эти суммы, т. о. хвала ему и почет. Но когда дело касается выгрузки в ДБФ-формате в БЭСТ Атол начинает филонить, отражая то, что продано смешанно, одной строкой с видом оплаты скажем "3", при этом ставиться крест на желании формировать проводки из режима "Учет розничных продаж" типа Д412 -К9021
т.к. по картам проводки выглядять совсем иначе (задействуется 57 счет). Ладно бы продавался один телевизор и скажем 50/50 тогда количество 0,5/0,5 и все красиво. А если пропорция другая или товара много? Тогда формирование проводко из учета розничных продаж по товару ввобще не имеет смысла. Нужен другой подход.

Раздел 2. Другой подход
А нельзя ли выгрузить виды оплат по суммам. Введите оплаты ручками две суммы, скажете вы. А если касс много? Хм... Может быть похожая возможность есть в КМП+?
Правда есть еще одна проблема! Как загрузить их в Бэст. Хотя тут уже можно что-то придумать.

попробую бороться в КПМа

для гепарда не подходит, похоже поддерживается Эпосом только протокол инкотекс 1 и 2, а нужен 3-й, который исключен из поддержки атолом начиная с версии общего драйвера 5.16