22.11.2016 17:01
Цитата:
bob А почему не УКМ2 TXT?
с BDE не надо возиться. в чем минусы по сравнению с парадоксовской?
А загрузка смен в СМ+ нормально идет?
дак хрен его знает...
я же старый как овно мамонта... и когда я это начинал настраивать никакого ТХТ в помине еще не было...
да и зачем если и так работает?
22.11.2016 20:04
Итак. постараюсь подвести итог из общения со student. В свет сопряжения с СМ+ последней версии. остальное меня не интересует.
1. Протокол УКМ4 (там есть признак алкоголя при выгрузке из СМ+ и есть проданные акцизки, которые фигурируют в чеках СМ+) не поддерживается пока. Протокол "тяжелый" и даже родной УКМ4 его всасывает достаточно долго. Это минус.
2. Протокол УКМ2 разных модификаций работает, но в этом случае нельзя хранить данные в базе SQL-сервера магазина (либо обмен УКМ2, либо обмен с базой SQL), где можно аккумулировать чеки (проданные акцизки по алкоголю, в частности и потом экспортировать их в СМ+ - что немаловажно).
3. Признак принадлежности алкоголю при использовании протокола УКМ2 необходимо выгружать из СМ+ отдельным файлом и грузить его в УКМВИН. Добиться синхронизации данных при заведении, исправлении карточек в СМ+ в данном случае проблематично. Так как при каждой выгрузке из СМ+ необходимо контролировать и выгружать параллельно каким-то образом признак принадлежности к алкоголю. Что значит проданная бутылка без акцизки я думаю объяснять не надо. Привязывать обновление всех алкогольных карточек к одной выгрузке в день выглядит сомнительно из-за человеческого фактора в первую очередь.
4. Использовать базу SQL-сервера и писать, или воспользоваться услугами konst, или jokerpnz для обмена между СМ+ и SQL? Дело не столько в платности, сколько в гарантии поддержки данной услуги в своевременности решения проблем в случае, например, изменения структуры таблиц. Человек отошел от дел и прочее. Бросать силы на разработку собственного решения - гипотетически те же грабли.

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

ЗЫ. про плюсы писать не буду - их много. если бы их не было, данныю тему я бы вообще не поднимал.
22.11.2016 23:45
я вообще не понимаю видимо проблемы...

у меня сделано так...
1. выгрузка из см в формате укм2 - db... там где х32 с индексами... где х64 - без индексов...

2. Кто сказал что обмен ТОЛЬКО!?!?!? у меня данные выгружаются из СМ, всасываются кассой, выгружаются в формате УКМ2, т.е. DB... paradox, НО!!?!? воперативная сводка настроена на sql сервер!!! единый для сети магазинов скажем в 5-10 штук...
на sql сервере есть КАЖДЫЙ чек! с акцизкой, суммой.. товаром и т.д. именно данный севрер используется для контроля при продаже повторных марок... если уже продали такую.. вторую продать не даст...

3. Что заничит проданная бутылка без акцизы? есть утилита написанная кстати не безизвестным и многоуважаемым многою джокером... это простейшая консольная штуковина которая лезет в базу и формирует файл Egais.csv. кладется он туда каждые 5 минут по расписанию, выгрузка в кассовом модуле каждые 10-15 минут. Касса в момент загрузки проверяет что вместе с выгрузкой из СМ есть egais.csv... и если его нет просигнализует тряпкой на весь экран (правда не разу не видел т.к. просто такого ниразу не было)... т.е. этот механизм работает ну месяцами точно и я даже к нему не прикасаюсь... т.е. за это уж точно не стоит преживать...

4. Сам недолюбливаю SQL... yно при контроле марок нужно чтото юзать.... вариантов тут не много mysql небесплатен для некомерческого использования...XE? хз еще одна редакция оракл на сервере? сомневаюсь что комуто такое надо...
mssql мною ненавистен однако по быстродействию скрости работы и надежности к нему претензий нет воошпе...
при задачах которые он решает в текущей ситуации...
23.11.2016 08:32
Цитата:
bob Если разработчики УКМВИН решат эти проблемы - это будет огромный плюс для них в этом вопросе. Вопрос один - нужно ли это им?
нам это м.б. и не совсем надо :) только вот сделать все равно придется, т.к. временами народ спрашивает такое решение
в настоящее время за это никто не возьмется, а вот после запуска 54фз вполне вероятно, тем более что наработки есть - начинали когда было непонятно как алкогольный признак передавать...
единственное что я до сих пор не пойму так это решения пихать хмл везде :( чем не устраивает обычный цсв, не требующий особых затрат как на формирование так и на чтение данных ?
конечно хорошо, когда все в одном файле (хмл) но когда этот файл поднять нельзя без дополнительных телодвижений то это ...

кстати, пришел новый протокол обмена с фр от с+ по 54фз - так вот там тоже хмл так что многие кто работал с фр в обход библиотек от с+ (напрямую) вероятнее всего задумаются - а оно того стоит ?
лично меня напрягает разбирать ответ типа
=====================
<CommandResponseData>&lt;?xml version="1.0" encoding="UTF-8"?&gt;&lt;ArmGetStatus&gt;&lt;LastCommand&gt;0&lt;/LastCommand&gt;&lt;LastCommandStatus&gt;92&lt;/LastCommandStatus&gt;&lt;CommandExecTime&gt;40&lt;/CommandExecTime&gt;&lt;FNStatus&gt;&lt;LifePhase&gt;3&lt;/LifePhase&gt;&lt;currentDoc&gt;0&lt;/currentDoc&gt;&lt;docData&gt;0&lt;/docData&gt;&lt;shiftState&gt;0&lt;/shiftState&gt;&lt;needChangeFN&gt;0&lt;/needChangeFN&gt;&lt;endingResourceFN&gt;0&lt;/endingResourceFN&gt;&lt;overflowFN&gt;0&lt;/overflowFN&gt;&lt;longWaitOFD&gt;0&lt;/longWaitOFD&gt;&lt;lastDocDateTime&gt;&lt;/lastDocDateTime&gt;&lt;FS_Number&gt;9999078900000772&lt;/FS_Number&gt;&lt;fiscalDocNumber&gt;7&lt;/fiscalDocNumber&gt;&lt;lifeTime&gt;2017-11-10 11:01:00&lt;/lifeTime&gt;&lt;version&gt;fn debug v 1.32&lt;/version&gt;&lt;/FNStatus&gt;&lt;OFDStatus&gt;&lt;status&gt;1&lt;/status&gt;&lt;ofdMessageReadStarted&gt;0&lt;/ofdMessageReadStarted&gt;&lt;ofdQueueLength&gt;0&lt;/ofdQueueLength&gt;&lt;firstQueueDocNumber&gt;0&lt;/firstQueueDocNumber&gt;&lt;firstQueueDocDateTime&gt;&lt;/firstQueueDocDateTime&gt;&lt;/OFDStatus&gt;&lt;/ArmGetStatus&gt;</CommandResponseData>
=====================
ради одного, требуемого мне параметра причем судя по перечню команд
=====================
5 ПЕРЕЧЕНЬ КОМАНД
GetStatus - получение статуса устройства
ShiftOpen - открытие смены
Receipt - регистрация чека
Correction - формирование чека коррекции
ShiftClose - закрытие смены
SettlementReport - получение отчета о текущем состоянии расчетов
Confirmation - подтверждение оператора
GetDocument - получение документа по номеру ФН
Registration - регистрация/перерегистрация, смена параметров
GetRegistrationinfo - отчет о регистрации/перерегистрации
GetTime - получение времени
SetTime - установка времени
FNClose - закрытие ФН.
=====================
то скорее всего (фр-а пока в живую нет) часть команд останется по старому
23.11.2016 09:43
XML, как я понимаю, для тех, кто сначала убивает время на форумах, выпрашивая XML-парсеры, а потом плодит вот такое поделие, поскольку не хочет считать какой графе в CSV что соответствует. На скорость работы и объем передаваемых данных наплевать...
23.11.2016 10:45
Цитата:
OlegON поскольку не хочет считать какой графе в CSV что соответствует
а что там считать ?
это же плоская таблица и работать с ним надо как с таблицей
именно поэтому у нас (укмвин) достаточно высокая скорость обработки для таких файлов - нет у нас тупого построчного чтения и разбора...

пы сы
отличное решение по работе с цсв - фри - работает с файлом как с обычной таблицей
CSVed 2.4 - CSVed is an easy and powerful CSV file editor, you can manipulate any CSV file, separated with any separator
ссылку не привожу - гуглится на раз\два
23.11.2016 10:57
по стоимости пока 2000 рублей за этот загрузчик со всеми фичами типа отчётов, акций и данных для егаис. разовый платёж, доп. доработки обсуждаются за отдельную плату. обновление, исправление ошибок, либо структура базы супермага вдруг поменяется естественно бесплатно. если программа пойдёт, то новым клиентам дороже буду продавать, тем кто оплатил доплачивать не придётся
на 3 месяца могу выдать программу, чтобы поработать и вообще определиться нужна ли она вам, а потом уж оплачивать. насчёт переживаний, что программа не будет поддерживаться, могу только пообещать отдать исходники в таком случае, если уж вдруг случится. с 2008 года не бросал его
23.11.2016 11:04
кстати, может кто подхватит. когда переписывал на шарп, были мысли написать небольшой конвертер. файлы, которые кассовый модуль выгружает запихать в скуль. структура базы одинаковая. на мой взгляд самый простой вариант, который и самому можно написать. смотреть в каталог, ждать флаг и писать в скуль, также и обратная конвертация из скуля в файл paradox или txt
23.11.2016 14:40
Цитата:
jokerpnz по стоимости пока 2000 рублей за этот загрузчик со всеми фичами типа отчётов, акций и данных для егаис. разовый платёж, доп. доработки обсуждаются за отдельную плату. обновление, исправление ошибок, либо структура базы супермага вдруг поменяется естественно бесплатно. если программа пойдёт, то новым клиентам дороже буду продавать, тем кто оплатил доплачивать не придётся
на 3 месяца могу выдать программу, чтобы поработать и вообще определиться нужна ли она вам, а потом уж оплачивать. насчёт переживаний, что программа не будет поддерживаться, могу только пообещать отдать исходники в таком случае, если уж вдруг случится. с 2008 года не бросал его
Платить то на какой-то кошелек или карту? не на юрлицо по безналу?
24.11.2016 10:59
Цитата:
bob Платить то на какой-то кошелек или карту? не на юрлицо по безналу?
Не на юрлицо. Кошелёк, карта, можно и на счёт по договору оказания услуг, как мне платили за EgaisHelper, например.
Если интересно, могу дать попробовать поработать, а то может и не нужно будет Вам
Часовой пояс GMT +3, время: 08:35.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.