[ОТВЕТИТЬ]
17.02.2015 15:59
tunkraft
 
Являюсь разработчиком кассового ПО.
Хочу поддержать формат УКМ для связки моей программы с товароучетной системой Супермаг.
Описание формата беру из файла "УКМ.A5.Стандарт Comma Separated(CSV).Описание интерфейса.doc"

В ходе реализации хочу объединить таблицы "PLUCASH.DAT" и "BAR.DAT" и запихнуть все данные из этих двух таблиц в свою внутреннюю. Это обусловлено тем, что моя кассовая программа поддерживает несколько товароучетных систем и, следовательно, форматов входных данных. Для унификации и чтобы не плодить лишних таблиц под каждую систему есть потребность такого объединения.
Но тут возникает проблема, когда в папке загрузки будет флаг "CASH.CNG". Это значит что я должен заменить все данные в тех таблицах, что будут лежать в папке загрузки, и не трогать таблицы, которые не будут выгружены товароучетной системой. Если в такой ситуации вместе с флагом "CASH.CNG" будет лежать только одна таблица "PLUCASH.DAT" или "BAR.DAT", то я потеряю в своей внутренней БД все данные из другой таблицы (которая была загружена ранее), т.к. у меня они объединены и перед загрузкой я очищу внутреннюю таблицу.

Отсюда вопрос к знатокам Супермага: Бывает ли в реальности такая ситуация, когда с флагом "CASH.CNG" будет лежать только одна таблица "PLUCASH.DAT" или "BAR.DAT"?

Просьба не анализировать факт объединения таблиц и не предлагать другие алгоритмы реализации. Прошу лишь ответить на мой вопрос.
Спасибо.
17.02.2015 17:03
student
 
Я не знаток супермага, но судя по логам нашей кассовой программы, такое происходит достаточно часто :)
что в принципе логично - не зачем передавать не измененные данные
17.02.2015 17:05
vdm
 
Нет. Супермаг выгружает артикулы только вместе с ШК. (в полной выгрузке т.е.)
17.02.2015 17:28
student
 
Цитата:
vdm Нет. Супермаг выгружает артикулы только вместе с ШК. (в полной выгрузке т.е.)
забавно, но м.б. у мне попадаются не правильные супермаги :)
в банках данных присылаемых для анализа достаточно часто идут либо артикулы либо шк по отдельности
правда там в основном дб (парадокс) загрузка и ещё напрягает практически постоянная загрузка только одного единственного классификатора :(
в дб варианте часто ранее попадался микс - артикулы - замена, шк - обновление - из-за чего пришлось у себя проверки при загрузке делать
так что я не стал бы говорить так однозначно - ситуация имеет право быть :)
17.02.2015 17:55
tunkraft
 
Интересно, мнения разделились...
Знатоки-Телезрители 1:1 =)
Может будут еще версии?
17.02.2015 18:06
vdm
 
Изначально упомянут cash.cng т.е. как я понял вопрос только про полную выгрузку.
Какой смысл при полной не выгружать ШК, например?
17.02.2015 18:18
student
 
Цитата:
vdm Какой смысл при полной не выгружать ШК, например?
самый примитивный :) скорость операции - изменение цены например - зачем лопатить шк если они не менялись ?
не знаю как сейчас а ранее попадалось что при превышении определленого кол-ва карточек вместо операции обновления данных супермаг формировал и выдавал флаг на замену данных
17.02.2015 19:14
vdm
 
"Не выгружать, если не изменилось" - это для инкрементальной выгрузки.
Если этот принцип распространять на полную - то на изменения нужно смотреть всегда и если менялись только цены - ШК не выгружать. Сомнительное поведение, если точно неизвестно, принял ли вообще фронт предыдущие выгрузки.

Я знатоком себя не мню, последних версий СМ не видел.
Но в доступных мне, такого поведения не представляю, сужу в том числе по внутренностям базы. "Количество изменений" тут смотрится в целом по количеству измененных артикулов. Т.е. полная - значит полная, несмотря на то что выгружалось раньше.
17.02.2015 19:56
student
 
Цитата:
vdm Я знатоком себя не мню, последних версий СМ не видел.
Но в доступных мне, такого поведения не представляю, сужу в том числе по внутренностям базы.
аналогично :)
меня более интересует фронт, и по его логам я и отписался (благо за 10 лет статистики набежало) и я ничего не утверждаю категорично :) просто пытаюсь донести мысль что все возможно и не значит что всегда шк будут идти вместе артикулами при замене в загрузке, особено если учесть что для дб (от которой все остальные отпочковались) загрузки в одном файле флага возможны и замены и обновления для различных таблиц данных, да и как доп. вариант формат загрузки укм не только супермаг юзает - он используется и другими товароучетками и не факт что там таже логика :)
чтобы что то работало тс надо исходить из того что все имеет право попадать в кассу как по отдельности так и в любых комбинациях независимо ни от чего :)
17.02.2015 21:30
baggio
 
из того что я вижу...
не может быть PLUCASH.DAT без BAR.DAT 99.99999999999999%
18.02.2015 07:01
Mtirt
 
Цитата:
baggio из того что я вижу...
не может быть PLUCASH.DAT без BAR.DAT 99.99999999999999%
Согласна с предыдущим оратором.
18.02.2015 07:52
student
 
Цитата:
baggio из того что я вижу...
не может быть PLUCASH.DAT без BAR.DAT 99.99999999999999%
это какие то не правильные пчелы и они делают неправильный мед :)
открыл банку - загрузка от супермага (присылали в начале года для проверки) - плукеш есть, а вот бара - нет :( так что все таки возможно все

PID_OPER OP:дата OP:пользователь OP:операция OP:касса
1053 01/12/2014 17:51:17 Кассир Терминал: загрузка: УКМ: флаг 4
1054 01/12/2014 17:51:17 Кассир Терминал: загрузка: УКМ: копирование 4
1055 01/12/2014 17:51:31 Кассир Терминал: загрузка: УКМ: начало 4
1056 01/12/2014 17:51:31 Кассир Терминал: загрузка: УКМ: обновление данных: PLUCASH 4
1057 01/12/2014 17:51:31 Кассир Терминал: загрузка: УКМ: обновление данных: CLASSIF 4
1058 01/12/2014 17:51:33 Кассир Терминал: загрузка: УКМ: обновление данных: SCALE 4
1059 01/12/2014 17:51:33 Кассир Терминал: загрузка: УКМ: обновление данных: SIZE 4
1060 01/12/2014 17:51:33 Кассир Терминал: загрузка: УКМ: обновление данных: PERSONAL 4
1061 01/12/2014 17:51:33 Кассир Терминал: загрузка: УКМ: обновление данных: CLASDISC 4
1062 01/12/2014 17:51:33 Кассир Терминал: загрузка: УКМ: обновление данных: CLASLIM 4
1063 01/12/2014 17:51:33 Кассир Терминал: загрузка: УКМ: обновление данных: CLICLASS 4
1064 01/12/2014 17:51:33 Кассир Терминал: загрузка: УКМ: обновление данных: DISCSUM 4
1065 01/12/2014 17:51:33 Кассир Терминал: загрузка: УКМ: обновление данных: DEPART 4
1066 01/12/2014 17:51:33 Кассир Терминал: загрузка: УКМ: обновление данных: TAX 4
1067 01/12/2014 17:51:33 Кассир Терминал: загрузка: УКМ: обновление данных: DCLISLST 4
1068 01/12/2014 17:51:34 Кассир Терминал: загрузка: УКМ: обновление данных: PRICEKIN 4
1069 01/12/2014 17:51:34 Кассир Терминал: загрузка: УКМ: окончание 4

смотрим далее

PID_OPER OP:дата OP:пользователь OP:операция OP:касса
1716 02/12/2014 15:02:12 Кассир Терминал: загрузка: УКМ: флаг 1
1717 02/12/2014 15:02:12 Кассир Терминал: загрузка: УКМ: копирование 1
1718 02/12/2014 15:02:24 Кассир Терминал: загрузка: УКМ: начало 1
1719 02/12/2014 15:02:24 Кассир Терминал: загрузка: УКМ: обновление данных: PLUCASH 1
1720 02/12/2014 15:02:25 Кассир Терминал: загрузка: УКМ: обновление данных: CLASSIF 1
1721 02/12/2014 15:02:25 Кассир Терминал: загрузка: УКМ: окончание 1

смотрим еще дальше

PID_OPER OP:дата OP:пользователь OP:операция OP:касса
3373 04/12/2014 19:57:46 Кассир Терминал: загрузка: УКМ: флаг 4
3374 04/12/2014 19:57:46 Кассир Терминал: загрузка: УКМ: копирование 4
3375 04/12/2014 19:57:58 Кассир Терминал: загрузка: УКМ: начало 4
3376 04/12/2014 19:57:58 Кассир Терминал: загрузка: УКМ: обновление данных: PLUCASH 4
3377 04/12/2014 19:57:59 Кассир Терминал: загрузка: УКМ: обновление данных: CLASSIF 4
3378 04/12/2014 19:58:00 Кассир Терминал: загрузка: УКМ: обновление данных: SCALE 4
3379 04/12/2014 19:58:00 Кассир Терминал: загрузка: УКМ: обновление данных: SIZE 4
3380 04/12/2014 19:58:00 Кассир Терминал: загрузка: УКМ: обновление данных: PERSONAL 4
3381 04/12/2014 19:58:00 Кассир Терминал: загрузка: УКМ: обновление данных: CLASDISC 4
3382 04/12/2014 19:58:00 Кассир Терминал: загрузка: УКМ: обновление данных: CLASLIM 4
3383 04/12/2014 19:58:00 Кассир Терминал: загрузка: УКМ: обновление данных: CLICLASS 4
3384 04/12/2014 19:58:01 Кассир Терминал: загрузка: УКМ: обновление данных: DISCSUM 4
3385 04/12/2014 19:58:01 Кассир Терминал: загрузка: УКМ: обновление данных: DEPART 4
3386 04/12/2014 19:58:01 Кассир Терминал: загрузка: УКМ: обновление данных: TAX 4
3387 04/12/2014 19:58:01 Кассир Терминал: загрузка: УКМ: обновление данных: DCLISLST 4
3388 04/12/2014 19:58:01 Кассир Терминал: загрузка: УКМ: обновление данных: PRICEKIN 4
3389 04/12/2014 19:58:01 Кассир Терминал: загрузка: УКМ: окончание 4

могу еще и из других банок наковырять, только вот смысла не вижу - я писал выше - не стоит закладываться на то что так всегда и везде будет
18.02.2015 08:10
Mtirt
 
Только это у тебя ИНКРЕМЕНТАЛЬНЫЕ выгрузки, судя по количеству данных...
А речь идет о ПОЛНОЙ.
При полной УКМ4 заменяет ВСЕ данные которые у него были данными из выгрузки.
При инкрементальной - дополняет.
18.02.2015 09:00
student
 
Цитата:
Mtirt Только это у тебя ИНКРЕМЕНТАЛЬНЫЕ выгрузки, судя по количеству данных...
А речь идет о ПОЛНОЙ.
При полной УКМ4 заменяет ВСЕ данные которые у него были данными из выгрузки.
При инкрементальной - дополняет.
4 - это не данные - это номер кассы

вот кусок с другого супермага (это утренний прием данных в кассу при включении - т.е. принимается все что супермаг за ночь навыкладывал) - там есть и то и то, правда мне до сих пор не понятно почему при замене только 2 таблички :)

PID_OPER OP:дата OP:пользователь OP:операция OP:касса
918 22/01/2015 7:48:17 не определен Терминал: загрузка: УКМ: флаг 404
919 22/01/2015 7:48:17 не определен Терминал: загрузка: УКМ: начало 404
920 22/01/2015 7:48:17 не определен Терминал: загрузка: УКМ: обновление данных: PLUCASH 404
921 22/01/2015 7:48:18 не определен Терминал: загрузка: УКМ: окончание 404
922 22/01/2015 7:48:18 не определен Терминал: загрузка: УКМ: начало 404
923 22/01/2015 7:48:18 не определен Терминал: загрузка: УКМ: обновление данных: PLUCASH 404
924 22/01/2015 7:48:18 не определен Терминал: загрузка: УКМ: окончание 404
925 22/01/2015 7:48:19 не определен Терминал: загрузка: УКМ: начало 404
926 22/01/2015 7:48:19 не определен Терминал: загрузка: УКМ: обновление данных: PLUCASH 404
927 22/01/2015 7:48:19 не определен Терминал: загрузка: УКМ: обновление данных: BAR 404
928 22/01/2015 7:48:19 не определен Терминал: загрузка: УКМ: окончание 404
929 22/01/2015 7:48:19 не определен Терминал: загрузка: УКМ: начало 404
930 22/01/2015 7:48:19 не определен Терминал: загрузка: УКМ: обновление данных: BAR 404
931 22/01/2015 7:48:19 не определен Терминал: загрузка: УКМ: окончание 404
932 22/01/2015 7:48:20 не определен Терминал: загрузка: УКМ: начало 404
933 22/01/2015 7:48:20 не определен Терминал: загрузка: УКМ: замена данных: CLASSIF 404
934 22/01/2015 7:48:20 не определен Терминал: загрузка: УКМ: замена данных: BAR 404
935 22/01/2015 7:48:21 не определен Терминал: загрузка: УКМ: окончание 404

обновление - инкрементная загрузка
замена - полная загрузка

дополнение - про замену данных - т.е. флаг полной загрузки - это опять таки уже с совершенно другого супермага :)

PID_OPER OP:дата OP:пользователь OP:операция OP:касса
1136 03/03/2014 10:05:41 Подосиновик А. Терминал: загрузка: УКМ: флаг 16
1137 03/03/2014 10:05:42 Подосиновик А. Терминал: загрузка: УКМ: начало 16
1138 03/03/2014 10:05:43 Подосиновик А. Терминал: загрузка: УКМ: замена данных: PLUCASH 16
1139 03/03/2014 10:05:44 Подосиновик А. Терминал: загрузка: УКМ: замена данных: CLASSIF 16
1140 03/03/2014 10:05:45 Подосиновик А. Терминал: загрузка: УКМ: окончание 16
18.02.2015 09:49
vdm
 
Может я невнимательно читал документацию. Но покажите мне, где для конвертера csv описано одновременное присутствие в каталоге и полной и инкрементальной выгрузки??? Это же не предусмотрено протоколом?
18.02.2015 10:14
student
 
Цитата:
vdm конвертера csv
все, сдаюсь, такого в принципе не возможно
насколько я понимаю - конвертер - только конвертирует те данные, что приготовил загрузчик - в нашем случае кассовый сервер
большинство из приведенных мной примеров от дб (парадокс) загрузки, но это не означает, что такой ситуации не может быть и для тхт и любой другой загрузки, поскольку кассовый сервер и там и там один и тот же или м.б. я не понимаю и в супермаге под каждый тип загрузки ставится свой кассовый сервер, что данные готовит перед конвертацией?
18.02.2015 10:17
Mtirt
 
Кассовый сервер один, но для каждого конвертера может быть своя логика работы приложения.
18.02.2015 11:08
student
 
Цитата:
Mtirt может быть своя логика работы приложения
а может быть и одинаковая
ключевое слово здесь - может - наверняка знают только разработчики, но они молчат как партизаны :(
да и кстати не факт что если здесь (тхт) логика другая то в следующих релизах не поменяют - если есть 2-е таблицы, то и обрабатку их у себя надо предусматривать в любой комбинации
18.02.2015 15:35
tunkraft
 
Всех благодарю.
Тема раскрыта.
Решил не объединять, дабы на 100% исключить форс-мажор.
Опции темы


Часовой пояс GMT +3, время: 17:00.

 

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