Пароль админа на УКМ4 : УКМ-4

Немножко о другом, у меня SAPа нет, это совсем другие деньги, со всеми его сущностями. Я даже не о поправке чеков и прочем, я именно о добывании информации. У меня дисконты большей частью идут в УКМ, не попадая в бек, маркетологи хотят эту информацию. Есть и другие поводы считать базу фронта уникальной, больше не кассовой, а сервера. Из инструментов - запросы к базе. В одну сторону - "из". Внутрь базы я ничего пихать не собирался, хотя это тоже приходится делать. Саппорт, кстати, тоже страдает тем же самым. Уж всякой фигни про файрволы и неправильные бубны я почитал. И знаю почему. Потому, что никто толком понять не может, как оно работает, что следует из запутанной структуры базы. Я не говорю о создании своих скидок и пр., хотя и это бы не помешало. Но нормальный человек не будет делать это без 100% уверенности и понимания того, что он делает. Что касается инструментов, то мне не нужен DOS, но и даже при наличии готового интерфейса для SOAP, мне нужно будет к нему привыкать, учить методы и пр., замусоривая и так сильно забитую голову, в то время, как таблички - вот они, бери и пользуйся тем, что уже знаешь. Все мощью и гибкостью SQL, насколько это применимо к MySQL. Я, например, питаю крайнюю неприязнь к веб-мордам и HTML. Ну повелось так. Считаю, что он тормозной, глючный и нестандартизованный. И так еще будет достаточно долгое время, если не всегда. И уверен, что многие со мной согласятся. Да, нововведения и новые технологии имеют право на жизнь, но не в RAD с повышенными требованиями к надежности. Мне не нравится SOAP тем, что нет возможности управлять транзакциями, как в обычной двузвенке, нельзя пользоваться блокировками и нельзя дать команду и забрать результат другой. Там совершенно другая идеология, не лишенная преимуществ, но мне, как достаточно далекому от разработки УКМ человеку, совершенно ненужная... Я не прошу убеждать меня в том, что SOAP это круто. Я говорю о том, что у меня куча общепризнанных универсальных инструментов, которыми можно решать тонну задач, зачем меня вынуждать учить что-то, что будет использоваться только в рамках УКМ4 (о том, что это где-то еще обязательно будет использоваться рассуждать не будем, я про текущую ситуацию), это же только сузит круг потенциальных разработчиков... Не надо приписывать мне лень и нежелание пользоваться перспективными наработками, они далеки от меня и мне не нужны. Для саморазвития разработчика и проекта они полезны, для админа - нет. В сутках всего 24 часа, а у меня профильное совсем другое направление и поверь, это не Doom. И выход есть - сделать хотя бы ядро базы с относительно фиксированной, четкой, описанной и логичной структурой, чего я и жду от ее ближайшего преобразования, тогда и подключусь разработкой...

Похоже принципиально о разном. К чему ты клонишь мою мысль я понял уже давно :) Наверное даже знал с самого начала.

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

А вот что мы можем обеспечить так это поддержку любой переферии, включая ФР, импорт/экспорт, скидки, продажу услуг и приём оплаты. Вот здесь действительно время выстроило некий стандарт и даже наши собственные разработчики ему следуют. То есть когда новый сотрудник на испытательном сроке в состоянии поддержать новый регистратор и при этом ничего не зная про то, как кассы цепляются к магазину, как работает синхронизация, какова структура БД и что такое СГО, говорит о том, что в той же Беларуси могут спокойно написать поддержку своего местного ФР со своей местной ЭКЛЗ и отдать нам готовый код для включения его в версию. Вот это мы обеспечить сможем. Кстати по этому принципу работает конвертер GOLD - есть некие люди, не будем их вежливо упоминать, которые написали запросы к ораклу и отдали их нам, на основании этих запросов работает их конвертер. Мы не трогаем их запрос, поскольку никто не понимает что он означает :), зато всегда поддерживаем его в рабочем состоянии и ребята не зависят от того, перестроили мы БД или нет. И ведь в принципе мы можем выложить исходник этого конвертера на sf.net, обговорить с вежливо неупомянутыми ребятами версионность и при сборке включать его в свой проект. И всё, когда им нужно они сами внесут исправления и в ближайшей версии, а то и в сервис паке их получат.

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

Именно так, когда я писал УКМ2 (сейчас думаю так же). Концепция была равно наоборот - сели придумали БД и больше её не меняли. На то была правда чисто техническая причина, но сути это не меняло. То есть волевым решением структура не менялась, даже несмотря на то, что это можно было бы сделать в угоду изменившимся требованием современной торговли. Даже сейчас, если снять это правило, то УКМ2 спокойно можно перестроить аналогично УКМ4.

Так вот, чтобы не готовить себе почву для УКМ5 или 6, мы если чувствуем, что структура БД, концепции которой уже лет
5, начинает нас не устраивать
мы её переделаем. Считать это метанием или нет, для меня вопрос неясный, поскольку у меня нет цели менять БД не реже чем nnn или не чаще чем mmm. Пришло время изменить - изменили, вот и всё. А навязывать самим себе статические вещи совершенно неоправданная роскошь, хотя конечно жизнь упрощает, поскольку много работы мы например делать бы просто не стали, например выпускать ресторан - нет в базе меню и баста, или структура чеков не была расчитана на заказы и предчеки и баста второй раз. Стоит оно того? На мой взгляд нет, тем более что я много лет писал по таким правилам УКМ2 и сформировал для себя именно такое мнение - фиксировать что-то просто ради самой фиксации задача не самая конструктивная.
Когда есть возможность быть гибким, нужно не терять гибкость. Когда код и структура закостенеют уже поздно будет что-либо предпринимать, пора будет думать о новом продукте.

Помогите решить вопрос. Есть сервер серверов УКМ 47sp5. По какой то причине изменилась системная дата на год вперед вовремя не заметил, позже поменял дату на актуальную но за это время укм записал чеки якобы годом вперед. А актуальные чеки после перевода даты не могут записаться.Вот лог из журнала сервера Бэкап укм отсутствует времени прошло много просто перезаписался.

А на СМ-ах думаю все нормально?
Если да то можно удалить чеки из базы СГО, проставить ID для vesions на значения поменьше. По идее чеки должны подняться с СМ-ов.
Я точно не знаю как все будет работать в случае с СГО.
Но попробовать можно если предварительно сделать бекапы СМ-ов и СГО.

Чеки в кассовый сервер поднимаются с временем кассы а не сервера
меняются id и vesions на серверные
серверный лог ведется временем сервера, только на что это влияет.

Доброго времени суток. Помогите кто может с следующим вопросом. Была в укм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верся. (((

Насколько я понимаю, TO_NUMBER('137,778','999D999','NLS_NUMERIC_CHARACTERS='',''') означает скидку в 137,778%
А скидка больше 100% быть не может.
Предлагаю прямо в файлах выгруженных данных процент скидки временно исправить на меньший (99,99 или 37,778), а сумму скидки не менять.
Потом посмотрим, что получится в результате приема данных.

Поменял, все получилось, блогодарствую в некоторых файлах стояло 900% скидка))). Тогда попутный вопрос по скидке в укм4. Когда завожу акцию с скидкой количество N на M, скидка на M сколько то процентов расчет вести для товара индивидуально, загрузка товара выбирается из файла а в нем тысяч 8 товара, при добавлении товара в список выбирается сперва какой столбец за что отвечает а потом индивидуально для каждого товара проставляется количество и другие параметры. По умолчанию при добавлении списка, в столбце скидка на M стоит стоимость и поправит все 8 тысяч руками не реально. Вопрос можно ли как нибудь сделать так чтобы при добавлении товара из файла по умолчанию стояло скидка?