[ОТВЕТИТЬ]
11.09.2007 15:54
alex_evil
 
Помогите проблема в следующем уехал админ и пропал не оставил пароль админа на УКМ, у остальных пользователей нет прав на создание и редактирование настроек, как можно поменять пароль админа.
11.09.2007 16:53
Mtirt
 
Я подозреваю, что потому и не оставил, что не надо настройки менять.
Может быть лучше обратиться в тех. поддержку в С+? У них, возможно, есть удаленный доступ и они могут поправить ситуацию...
12.09.2007 07:32
alex_evil
 
Ну если вы считает правильным не заводить новых кассиров и менять пароли старшим кассирам, то удачи вашему магазину!
Админ ПРОПАЛ поэтому и нужно сменить пароль.
Простота так от делать нечего я бы не писал.
12.09.2007 07:34
Mtirt
 
Заводить кассиров и менять пароли можно в См2000. Для этого не нужен доступ в УКМ.
Я вам предложила способ решения проблемы. Чем он вас не устраивает?
12.09.2007 08:39
alex_evil
 
Спасибо за совет. *65 (по нему сейчас и работаю).
Там стоит 1С а не СМ2000.
12.09.2007 11:02
votTAKOY
 
Подключаешься к базе ukmserver (например SQLYogom). Открываешь таблицу srv_user.И просто копируешь пароль из поля password любого известного тебе пользователя в поле админа. Это если, конечно, админ не задал пароль для ползователя root в базе ukmsrver (по умочанию без пароля).
12.09.2007 11:09
votTAKOY
 
Ну или можно отключить проверку пароля при входе в WEB. Добавить одну строчку в код (код то открыт).
17.09.2007 08:56
alex_evil
 
*44 votTAKOY. Спасибо! Огромное все получилось.
Только одно но существует в версии УКМ 37 pac 4 нет такое таблицы srv_user.
но есть другая security_user.
Еще раз Спасибо!*33
С меня пиво.
05.10.2007 17:41
shebdim
 
Хотел ответить с самого начала, но мне показалось что это не этично по отношению к самому себе :)
06.10.2007 14:47
votTAKOY
 
Цитата:
shebdim Хотел ответить с самого начала, но мне показалось что это не этично по отношению к самому себе :)
Извините, больше не буду. *129
06.10.2007 15:00
shebdim
 
Цитата:
votTAKOY Извините, больше не буду. *129
намана намана :) мне как раз очень приятно, что-то кто-то полазил и извлёк пользу от того, что текст открыт. вот если бы ещё кто-нить отчётов нарисовал или ещё какую полезность, мы бы репозиторий пользовательских страниц сформировали. эх, красота была бы :)
06.10.2007 15:40
votTAKOY
 
Идея очень правильная.
По поводу дополнительных отчетов клиенты у нас уже начинают интересоваться, правда пока никто еще не изложил это в виде нормального тех. задания.

Так, что пока, в целях собственного развития пытаюсь, что-то вывести на экран (например динамику чеков в виде графиков - пользы наверное мало - зато красиво :), или например количество логинов и логаутов в течение рабочего дня по кассе - можно сделать некоторые предположения, а правильно ли кассир выключила кассу)
06.10.2007 15:50
OlegON
 
Если бы база была вменяемая, описание и структура :( А то вот перейдете на 5 мускул, часть не будет работать на новом...
07.10.2007 02:48
shebdim
 
Цитата:
OlegON Если бы база была вменяемая, описание и структура :( А то вот перейдете на 5 мускул, часть не будет работать на новом...
Разрешать пользоваться внутренними механизмами для нештатных разработчиков в не opensource продукте путь либо сразу же тупиковый либо очень тернистый для желающих там копаться. Структура БД однозначно является именно внутренним знанием. И даже когда мы пишем стандартный конвертер, мы всегда делаем прослойку в виде ещё одной базы для обмена. Платим этой базой за возможность менять внутреннюю структуру без оглядки на последствия. Конечно чудес тут нет, и в случае изменения внутренней структуры приходится затрагивать все конвертеры, но зато это происходит подконтрольно.

И когда я говорю про написание своего отчёта (например) я прежде всего имею ввиду следующую последовательность:

- IT отдел на какой-то версии УКМ построил свой отчёт
- Передал отчёт нам
- С этого момента поддержание отчёта в работающем состоянии от версии к версии наша головная боль.

что получаем мы - практичный отчёт, прошедший проверку "боем", чем платим - необходимость тащить "отчёт" вс. оставшуюся жизнь

что получает клиент - нужный ему отчёт, плюс гарантию поддержки этого отчёта силами СП в будущих версиях. чем платит - IT ресурсом, которому пришлось копаться в наших внутренностях, писать и отлаживать отчёт.

таким образом, версия мускула, структура и прочий инструментарий не мешают использовать
внешний код.
07.10.2007 09:01
OlegON
 
В этом случае есть рамки вашего нежелания поддерживать какие-то отчеты и костыли и время на их апгрейд, а так же нежелание разработчика передавать вам код по каким-то причинам (например, чтобы не становиться заложником того же апгрейда). В эти рамки уложится очень многое. Я думаю даже бОльшая часть. Например, есть у меня какой-то свой отчет, я, естественно, хочу, чтобы он работал сейчас и три версии спустя. Итак, чтобы его передать вам, я должен его вам объяснить, потратив личное или рабочее время, теряю возможность его менять по собственному усмотрению даже незначительно (доступа к вашему репозиторию у меня нет), далеко не факт, что он вам нужен и вы будете его поддерживать, далеко не факт, что кто-то не попросит его изменить и эти изменения не будут противоречить моим целям, неизвестно, как разрешится ситуация, если вы проапгрейдив его один раз не откажетесь от функционала в следующей версии, заставив меня пройти две версии и копаться в том, что я забыл. Так что лучше тернистый путь самостоятельной поддержки и именно поэтому я для УКМ4 ничего не пишу. А вот заняться редизайном и оптимизацией структуры базы надо по любому, самим проще будет да и при текущем подходе коллапс все равно когда-нибудь наступит. Кому надо - справятся и с этой структурой, а вот добровольную стороннюю разработку, на которую вы и расчитываете, нынешнее положение вещей сильно тормозит.
07.10.2007 13:42
shebdim
 
Цитата:
OlegON А вот заняться редизайном и оптимизацией структуры базы надо по любому, самим проще будет да и при текущем подходе коллапс все равно когда-нибудь наступит. Кому надо - справятся и с этой структурой, а вот добровольную стороннюю разработку, на которую вы и расчитываете, нынешнее положение вещей сильно тормозит.
Если говорить объективно, то написание пользовательского кода в УКМ мероприятие маловероятное совсем по другим причинам. Во-первых, это малоинтересно. И объясняется это положением системы о общей инфраструктуре. Система находится на самом нижнем уровне иерархии и если и нуждается в пользовательском коде, то только в части соединения УКМ и какой-то другой системы. Однако, если пользователь всё-таки преодолев все сложности был вынужден самостоятельно писать код для УКМ, значит мы как разработчики что-то прощёлкали и нам важно понять что. Во-вторых, использовать код который написан не нами для работы с деньгами людей очень опасно. Ведь с одной стороны в случае проблем ответственность ляжет на нас, а с другой стороны максимум что мы можем сделать это посетовать на чужой код.

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

select id, name from tram_tam_tam.trun_tun_tun

а так и пишет - get_document_list()

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

то есть единственным устойчивым решением я вижу в создании публичных программных интерфейсов. с одной стороны, мы их публикуем и создаём себе геморрой по их поддержке, с другой стороны, если это будет востребовано, значит это снимет лишнее взаимодействие между подразделениями и ИТ отделы не обращаясь к нам, на опубликованных интерфейсах смогут делать что-хотят. Мы самим фактом публикации интерфейса гарантируем его неизменность.

Примеров тому даже сейчас существует несколько - есть интерфейс взаимодействия с платёжной системой, любой кто хочет использовать свои карты, со своими счетами может этим воспользоваться. Импорт экпорт данных - описано, можно пользоваться, от внутренней структуры не зависит! Система видеонаблюдения (а по факту просто нотификатор событий), подключайся, все данные описаны и фактически распрастраняются.

Я ещё раз хочу подчеркнуть, что желание писать со стороны важно по двум причинам - первое, это может означать нехватку чего-то важного, что можно вставить в продукт и второе, на основании этого можно сформировать интерфейс и опубликовать его.

Нет никакого желания в качестве такого интерфейса отдавать например БД. Во-первых для решения пользовательских задач структура данных может показаться слишком громоздка (кстати когда данные проходят через импорт экспорт для пользователя они представляются в сильно упрощённом виде)
. Во-вторых, за две ближайшие версии нам нужно решить две задачи, которые кардинально повлияют на структуру - отказаться от серверной схемы и перейти на распределённую и вторая разделить понятие документа в работе и документа в БД, там образом мы хотим сильно сократить количество таблиц и связей между ними. Если бы мы публиковали БД, этот путь был бы либо закрытым либо мы бы здорово подставили тех, кто что-то написал.
07.10.2007 13:58
OlegON
 
То, что желание писать есть - однозначно. Причем некоторые вещи имеют сугубо личный, частный характер. Для полного отвлечения пользователя от структуры БД придется писать неимоверно широкий интерфейс плагинов, что не представляется разумным. Более того, при открытости и логичности структуры БД можно ловить глюки общими усилиями и привлекать все новых разработчиков без длительного вникания в суть дела, да и охватывать одним разработчиком более широкий круг задач. Насчет подстав со сменой структуры, думаю, если задумка удастся, то подстава оправдается упрощением решения кучи других задач. В нормальных условиях не требуется кардинальной смены структуры и разработчики со стороны нормально адаптируются к ее смене.
07.10.2007 14:50
shebdim
 
Цитата:
OlegON То, что желание писать есть - однозначно.
Спрашивал специально, но никто не ответил - зачем? Поэтому пока я вижу только беспредметное желание. А это очень зыбкая основа для каких либо действий со стороны разработчиков УКМ для привлечения внешних разработчиков. Я думаю мы сделаем так, у нас уже сформировалось несколько интерфейсов готовых к публикации, сейчас разберёмся со стандартом и быть может официально откроем их. Пока рассматриваются SOAP и D-BUS, пока перевес на стороне SOAP. Откроем и при возникновении подходящих задач постараемся их решить снаружи, если это удасться, будем считать неплохим началом и в дальнейшем развивать эту тему.

На данный момент статус интереса к внешнему коду выглядит так - "было бы здорово, но, в принципе, по барабану" :)
07.10.2007 17:01
OlegON
 
Никто не может тебе назвать что-то монументальное, но запросы к базе пишутся, думаю, большинством вменяемых людей, работающих с УКМ4. Что касается SOAP, то мне, если честно, не хочется сидеть и разгребать эти XML-навороты и изучать вашу спецификацию к ним. Есть база и желание быстро добыть из нее информацию, имея минимальную квалификацию и уже существующие инструменты.
Люди не сидят и бездельем не маются, тут все на бегу... Все это шашечки, а нужно ехать, причем как правило сроки - "вчера". Куча внедряемых технологий не нужна, среднестатический админ, имея зоопарк софта и запаренный вопросами юзеров не будет сидеть и листать талмуд с трилогию Толстого. А вот из вменяемой структуры базы выдернуть запросом то, что ему отдел маркетинга напилил - запросто. Прикинь, как ты увеличиваешь стоимость штатной единицы, способной обслуживать магазин на УКМ? Зачем такой человек пойдет в магаз, если он может идти в ЦУП работать с такими знаниями?
07.10.2007 22:43
shebdim
 
Цитата:
OlegON но запросы к базе пишутся, думаю, большинством вменяемых людей, работающих с УКМ4
Мне известно только два примера, и то это наши саппортеры написали - дамп чека из БД и разрушение последнего чека.

Цитата:
OlegON Что касается SOAP, то мне, если честно, не хочется сидеть и разгребать эти XML-навороты
А это и не требуется, ведь никого не пугает подключение через клиента Oracle к его серверу БД? А там протокол похлеще, одна авторизация чего стоит. SOAP это просто инструмент, даже я бы сказал просто транспорт. Пользователю нужно знать название функции и параметры, проще мне кажется уже некуда :) SOAP хорош тем, что только что из-под DOS тебе не удасться обратиться к нужному коду, во всех остальных случаях всё готово, написано и шарит без проблем. А вот из-под DOS действительно нужно покопаться и в TCP/IP, и в HTTP, и в XML и наконец в SOAP.

Цитата:
OlegON Есть база и желание быстро добыть из нее информацию, имея минимальную квалификацию и уже существующие инструменты.
Я уже говорил, что само положение УКМ в структуре магазина не даёт оснований полагать, что в его БД, есть что-то уникальное и очень интересное, это может для бэкофисов справедливо, а в кассе делать в этом море чеков совершенно нечего. Ведь все справочники пришли из бэка, а все чеки ушли в бэк обратно. Фронт по сути своей получается петлёй, которая начинается в бэке, проходит через покупателя и возвращается обратно в бэк. В этом его смысл.

И потом быстро добыть информацию это вовсе не то, что я называю разработкой. Меня гораздо больше интересуют вещи, которые по объективным причинам проще сделать ИТ ресурсами клиента. Банальная скидка любой заковыристости от самой сложной до самой простой нуждается в экспорте своих правил в УКМ и чёткой алгоритмизации поведения на кассе. А ведь всё это в принципе на стороне клиента давно известно. Например, SAP сводобно умеет обращаться к веб сервисам. Уже содержит средства программирования. Позволяет создавать свои сущности и описывать структуру хранения. Так зачем имея такую мощь пытаться экспортировать скидки и заказывать у С+ новый алгоритм расчёта скидки? Ведь мы можем организовать запрос из УКМ в САП, передать всё, что у нас на данный момент известно о текущем чеке - позиции, платежи, существующие скидки, дисконтные карты и так далее, а нам просто сообщат какую скидку дать. И всё! Никакого лазанья по БД (САП по своей, мы по своей), а тем не менее скидка работает на стороне САП и без всякого усилия с нашей стороны оказывается в УКМ.
07.10.2007 23:27
OlegON
 
Немножко о другом, у меня SAPа нет, это совсем другие деньги, со всеми его сущностями. Я даже не о поправке чеков и прочем, я именно о добывании информации. У меня дисконты большей частью идут в УКМ, не попадая в бек, маркетологи хотят эту информацию. Есть и другие поводы считать базу фронта уникальной, больше не кассовой, а сервера. Из инструментов - запросы к базе. В одну сторону - "из". Внутрь базы я ничего пихать не собирался, хотя это тоже приходится делать. Саппорт, кстати, тоже страдает тем же самым. Уж всякой фигни про файрволы и неправильные бубны я почитал. И знаю почему. Потому, что никто толком понять не может, как оно работает, что следует из запутанной структуры базы. Я не говорю о создании своих скидок и пр., хотя и это бы не помешало. Но нормальный человек не будет делать это без 100% уверенности и понимания того, что он делает. Что касается инструментов, то мне не нужен DOS, но и даже при наличии готового интерфейса для SOAP, мне нужно будет к нему привыкать, учить методы и пр., замусоривая и так сильно забитую голову, в то время, как таблички - вот они, бери и пользуйся тем, что уже знаешь. Все мощью и гибкостью SQL, насколько это применимо к MySQL. Я, например, питаю крайнюю неприязнь к веб-мордам и HTML. Ну повелось так. Считаю, что он тормозной, глючный и нестандартизованный. И так еще будет достаточно долгое время, если не всегда. И уверен, что многие со мной согласятся. Да, нововведения и новые технологии имеют право на жизнь, но не в RAD с повышенными требованиями к надежности. Мне не нравится SOAP тем, что нет возможности управлять транзакциями, как в обычной двузвенке, нельзя пользоваться блокировками и нельзя дать команду и забрать результат другой. Там совершенно другая идеология, не лишенная преимуществ, но мне, как достаточно далекому от разработки УКМ человеку, совершенно ненужная... Я не прошу убеждать меня в том, что SOAP это круто. Я говорю о том, что у меня куча общепризнанных универсальных инструментов, которыми можно решать тонну задач, зачем меня вынуждать учить что-то, что будет использоваться только в рамках УКМ4 (о том, что это где-то еще обязательно будет использоваться рассуждать не будем, я про текущую ситуацию), это же только сузит круг потенциальных разработчиков... Не надо приписывать мне лень и нежелание пользоваться перспективными наработками, они далеки от меня и мне не нужны. Для саморазвития разработчика и проекта они полезны, для админа - нет. В сутках всего 24 часа, а у меня профильное совсем другое направление и поверь, это не Doom. И выход есть - сделать хотя бы ядро базы с относительно фиксированной, четкой, описанной и логичной структурой, чего я и жду от ее ближайшего преобразования, тогда и подключусь разработкой...
08.10.2007 00:34
shebdim
 
Цитата:
OlegON Немножко о другом
Похоже принципиально о разном. К чему ты клонишь мою мысль я понял уже давно :) Наверное даже знал с самого начала.

И хотел я сказать вот что. Иметь обязательства строить БД с учётом выборки оттуда информации в частном разрезе мы не сможем. У нашей БД масса задач, которую мы должны решать. Когда мы говорим про академическую стройность структуры, то тут важно понимать, что сама по себе структура нам не интересна. Нам важно, чтобы объекты автоматически писались/читались, нам важно быстро понимать сколько записей на какой сервер переслать, важно не зависеть от целостности справочников бэка важно ещё много чего. И если к этому ко всему приложить желание людей со стороны даже просто читать, то мы фактически станем пленниками собственной БД, чего бы крайне не хотелось. Поэтому даже если какая-то очередная структура кому-то покажется достойной для программирования, то это не значит, что она зафиксировалась и можно кодить тыщи строк текста. Структуру мы будем гнуть в ту сторону, куда нам выгоднее. Нет никакого желания фиксировать структуру БД. Мы её строим из задач нам известных, заложить потребности внешних программистов мы не сможем. Вот решили отказаться от БД сервера и БД кассы а иметь одинаковую и там и там, хоп! и сделали, при этом в тех местах где мы давали обязательства, всё осталось по-прежнему, а мы получили возможность построить кассу с функциями сервера, или например отказаться от локальной БД и всё писать со всех касс сразу в централизованную. То есть мы решили свою задачу, при этом не затронули внешний мир. С открытой структурой БД такой гибкости мы будем лишены. Захотелось нам по-армянски писать или по-грузински, хоп! снесли старый мускул, поставили новый, БД перевели в юникод. Свою задачу решили, обязательства сохранили. Потому, что это ядро и мы не можем себе позволить строить своё ядро из чисто гипотетических потребностей сторонних разработчиков. Это просто необоснованное ограничение. Я допускаю, что в какой-то момент кончатся идеи и мы перестанем придумывать что-то новое, вот тогда и зафиксируем БД, но тогда и продукт будет в общем-то не жилец.

А вот что мы можем обеспечить так это поддержку любой переферии, включая ФР, импорт/экспорт, скидки, продажу услуг и приём оплаты. Вот здесь действительно время выстроило некий стандарт и даже наши собственные разработчики ему следуют. То есть когда новый сотрудник на испытательном сроке в состоянии поддержать новый регистратор и при этом ничего не зная про то, как кассы цепляются к магазину, как работает синхронизация, какова структура БД и что такое СГО, говорит о том, что в той же Беларуси могут спокойно написать поддержку своего местного ФР со своей местной ЭКЛЗ и отдать нам готовый код для включения его в версию. Вот это мы обеспечить сможем. Кстати по этому принципу работает конвертер GOLD - есть некие люди, не будем их вежливо упоминать, которые написали запросы к ораклу и отдали их нам, на основании этих запросов работает их конвертер. Мы не трогаем их запрос, поскольку никто не понимает что он означает :), зато всегда поддерживаем его в рабочем состоянии и ребята не зависят от того, перестроили мы БД или нет. И ведь в принципе мы можем выложить исходник этого конвертера на sf.net, обговорить с вежливо неупомянутыми ребятами версионность и при сборке включать его в свой проект. И всё, когда им нужно они сами внесут исправления и в ближайшей версии, а то и в сервис паке их получат.
08.10.2007 10:37
OlegON
 
Я на самом деле предлагал сформулировать общую идею, концепцию. Метания и перестройки базы говорят о том, что эта самая идея постоянно меняется. А это в свою очередь ведет к повышенным трудозатратам со стороны разработчиков. Я не говорю о преимуществах того, что интерфейс с железками определен и новые сотрудники могут его поддерживать, я говорю о том, что структуру можно гнуть туда, куда выгоднее разработчику, стороннему или внутреннему - без разницы. Если вы согласны устроить себе геморрой по переписыванию кода из-за смены структуры, значит это должно быть оправдано и для любого разработчика. Если вся база переписывается от версии к версии, то логичнее сесть, обдумать структуру, продумать возможные пути развития и единожды оптимально структуризовать данные с учетом всех оптимизаций. Чем каждый раз ломать голову над тем, что будет, если тут оторвать или подклеить еще один столбец. Если не ломаете голову - замечательно, дайте возможность и другим не ломать, если ломаете, то пора бы и привести в порядок это дело...
08.10.2007 13:14
shebdim
 
Цитата:
OlegON Метания и перестройки базы говорят о том, что эта самая идея постоянно меняется
Именно так, когда я писал УКМ2 (сейчас думаю так же). Концепция была равно наоборот - сели придумали БД и больше её не меняли. На то была правда чисто техническая причина, но сути это не меняло. То есть волевым решением структура не менялась, даже несмотря на то, что это можно было бы сделать в угоду изменившимся требованием современной торговли. Даже сейчас, если снять это правило, то УКМ2 спокойно можно перестроить аналогично УКМ4.

Так вот, чтобы не готовить себе почву для УКМ5 или 6, мы если чувствуем, что структура БД, концепции которой уже лет
5, начинает нас не устраивать
мы её переделаем. Считать это метанием или нет, для меня вопрос неясный, поскольку у меня нет цели менять БД не реже чем nnn или не чаще чем mmm. Пришло время изменить - изменили, вот и всё. А навязывать самим себе статические вещи совершенно неоправданная роскошь, хотя конечно жизнь упрощает, поскольку много работы мы например делать бы просто не стали, например выпускать ресторан - нет в базе меню и баста, или структура чеков не была расчитана на заказы и предчеки и баста второй раз. Стоит оно того? На мой взгляд нет, тем более что я много лет писал по таким правилам УКМ2 и сформировал для себя именно такое мнение - фиксировать что-то просто ради самой фиксации задача не самая конструктивная.
Когда есть возможность быть гибким, нужно не терять гибкость. Когда код и структура закостенеют уже поздно будет что-либо предпринимать, пора будет думать о новом продукте.
07.04.2011 13:59
DIMAJBL
 
Помогите решить вопрос. Есть сервер серверов УКМ 47sp5. По какой то причине изменилась системная дата на год вперед вовремя не заметил, позже поменял дату на актуальную но за это время укм записал чеки якобы годом вперед. А актуальные чеки после перевода даты не могут записаться.Вот лог из журнала сервера Бэкап укм отсутствует времени прошло много просто перезаписался.
07.04.2011 18:03
didinap
 
А на СМ-ах думаю все нормально?
Если да то можно удалить чеки из базы СГО, проставить ID для vesions на значения поменьше. По идее чеки должны подняться с СМ-ов.
Я точно не знаю как все будет работать в случае с СГО.
Но попробовать можно если предварительно сделать бекапы СМ-ов и СГО.
12.04.2011 22:02
konopada
 
Чеки в кассовый сервер поднимаются с временем кассы а не сервера
меняются id и vesions на серверные
серверный лог ведется временем сервера, только на что это влияет.
23.06.2011 07:04
DIMAJBL
 
Доброго времени суток. Помогите кто может с следующим вопросом. Была в укм4 настроена акция на скидку но получилось так что за место скидки пошла наценка в ряде случаев надбавка и товар продавался в большую сторону от своей розничной цены. Кассиры вовремя не заметили. А проблема в следующем, что при попытке кассового модуля забрать продажи с касс заканчивается тем что фаилы которые в обменнике лежат так и остаются там лежать. В логах кассового модуля ошибок нет а в системных событиях приложения ошибка[Ошибка при попытке импорта записи из таблицы CASHDISC. Ключ записи "ShopIndex=4,CashNumber=2,ZNumber=467,CheckNumber=170,ID=24,DiscountIndex=0" Запись 2. Код=80004005h (2290) [Microsoft OLE DB Provider for Oracle]:ORA-02290: check constraint (SUPERMAG.SMCASHDISC_PERCENT) violated Запись 3. Код=80004005h (0) [SmLibaryBase trace]:
insert into Supermag.SMCASHDISC(LocID,DeskNum,ZNum,CheckNum,Item,DiscKind,Percent,DiscSum)values(4,2,467,170,24,0,TO_NUMBER('137,778','999D999','NLS_NUMERIC_CHARACTERS='','''),TO_NUMBER('6,2','9D9','NLS_NUMERIC_CHARACTERS='','''))%4 %5 %6 %7 %8]
Пробовал в файле CASHSAIL.DAT наити товар который продался с наценкой поправить на правильную цену не помогло. По ошибке нарушение проверки целостности я так понимаю. Возможно в супермаге где то не настроено что бы товар может продаватся с наценкой или надбавкой. Таким образом в воздухе весит довольно большая сумма денег и не списанного товара. Что делать? Все случилось после настройки акции в УКМ4 47верся. (((
23.06.2011 07:10
Mtirt
 
Насколько я понимаю, TO_NUMBER('137,778','999D999','NLS_NUMERIC_CHARACTERS='',''') означает скидку в 137,778%
А скидка больше 100% быть не может.
Предлагаю прямо в файлах выгруженных данных процент скидки временно исправить на меньший (99,99 или 37,778), а сумму скидки не менять.
Потом посмотрим, что получится в результате приема данных.
23.06.2011 09:24
DIMAJBL
 
Поменял, все получилось, блогодарствую в некоторых файлах стояло 900% скидка))). Тогда попутный вопрос по скидке в укм4. Когда завожу акцию с скидкой количество N на M, скидка на M сколько то процентов расчет вести для товара индивидуально, загрузка товара выбирается из файла а в нем тысяч 8 товара, при добавлении товара в список выбирается сперва какой столбец за что отвечает а потом индивидуально для каждого товара проставляется количество и другие параметры. По умолчанию при добавлении списка, в столбце скидка на M стоит стоимость и поправит все 8 тысяч руками не реально. Вопрос можно ли как нибудь сделать так чтобы при добавлении товара из файла по умолчанию стояло скидка?


Опции темы


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

 

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