Форум OlegON > Программы и оборудование для автоматизации торговли > Системы автоматизации торговли > КИС Lack & УС Land

Занятные замечания по программам семейства УС Лэнд от реальных пользователей : КИС Lack & УС Land

25.02.2024 17:31


21.04.2022 11:31
AndreyZh
 
Зачастую пользователи обращаются с нестандартными вопросами или запросами, а иногда замечают ошибки в программах, исправления которые приводят к обнаружению "нежданчиков" и глобальной переделки системы... Вот, например недавно присланный скрин с вопросом - как такое могло произойти?





… и одна из глобальных проблем, выявленных при анализе скрина. Выявлено, т.к. обычно использую данные от пользователей просто для отладки нюансов программы, а "вне" этих нюансов данные не анализирую, а посему иногда получаются такие неожиданности.

Последний код документа == ZVMU, т.е за время работы фирмы с программой было создано более 1.7млн безналичных операций и счетчик документов - уникальных кодов уже очень близко к пределу == ZZZZ (36-ричное число). Удивительно, т.к. голова забита другими задачами, но вспомнил, что уже предполагал у них такую ситуацию и в версии 2112 системы продумал и сделал перекодировку счетчика по данным типам документов в программа hLv... Ну а дальше, когда все ушли с работы автоматом преобразовал коды и получилось:





… но это была лишь одна прблемища выявленная на скрине => продолжение следует
26.04.2022 08:05
AndreyZh
 
Продолжение - окончание:

Изначально, где видны все проблемы было в письме со скрином:





Проблема была сложной для понимания, т.к. задающий вопрос не помнил, как это сделала? Следовательно нужно было найти способ, как её повторить. В программе есть много способов привязать оплаты к накладным, что даёт возможности для многих аналитик, хотя с позиции "аналитики" привязки не обязательны. Перепробовал все способы, например, когда задаём сумму платежа, а программа сама автоматом подбирает накладные для привязки:





Всё работало чётко, пока не "нащупал"... В списке накладных для оплаты (привязки) можно для самоконтроля задать общую сумму платежа и ручками подобрать под неё накладные, а программа просто контролирует, что бы сумма по отобранным ТТН не превысила заданную.





Хвост оплаты создаёт отдельный непривязанный к ТТН платеж. Так вот, если указать сумму точно равную подобранным ТТН, программа создавала липовый документ с нулевой суммой. Осталась "последняя" загадка - почему привязан нулевой платеж к накладной?

Оказалось, что программа честно и тупо отражала список накладных с непривязанным хвостом меньше или равным нулевой сумме финансового документа, т.е. полностью оплаченных и к ним можно было привязать нулевую сумму в режиме «^ -> Связать с товарно-транспортной накладной»... Исправил эту некритичную ситуацию заблокировав привязку нулевых сумм и отбор полностью оплаченных накладных.
18.07.2022 14:38
AndreyZh
 
Сегодня разрешилась "загадка десятилетия" для системы "УС Land"! Ура!!!

Более десяти лет периодически, примерно раз в 3-5 месяцев, возникала неприятная ситуация. Появлялась полностью дублированная запись по работнику и исчезал из справочника руководитель предприятия, ссылка на которого имеется во всех типах документов. Это было удивительно, т.к. ошибка появлялась только у одного клиента и абсолютно непредсказуемым образом. Конечно она несложно исправлялась, но руководителю каждый раз приходилось заполнять свои реквизиты, т.е. инфа о косяках в работе программы каждый раз доходила до него.

Причина пыталась каждый раз найтись, но безуспешно - небольшая таблица простой структуры, редко изменяемая по сети. Десятки раз мной изучался и переписывался код с целью не допустить её в последующем. Единственный эффект - она стала гораздо реже появляться. Более того один раз уже в состоянии "истерики" выставил бутылку дорого вина перед 4 очень умными операторами для того, кто ошибку сможет воссоздать... Всё тщетно - они меня уже успокаивали, что она особо на работу не влияет, да и возникает крайне редко...

Сегодня она появилась снова.На удачу - оператор сделал минимум операций в программе и запустил проверку логики, а посему запомнил, что лишь у водителя, который появился в дубле она изменила атрибуты водительского удостоверения... и больше ничего. Как обычно по удаленке убрал дубль, руководитель, как обычно снова занес свои реквизиты... и через пару минут снова дубляж этого водятла появился.

Снова восстановил данные, но пока не нагружая начальника попросил ещё раз проверить изменение строки справочника... медленнее... и тут до меня "доходит", что код руководителя указывается в карточке работника. Меняю карту другого работника, у которого нет руководителя - дубляжа не даёт. Меняю карту у "злополучной" записи, но удаляю код руководителя - не даёт дубляжа... Пока говорю при изменении карты стирать ненужный код руководителя и начинаю изучения у себя в тестовой БД. Злополучный атрибут есть на скрине:





В сотый раз изучаю код - всё "чисто". Начинаю вспоминать - нафига нужен этот атрибут. Вспомнил - более 15 лет назад в систему были введены 100% "кадры", а потом их удалил, а так же это поле использовалась при работе с автозаказами от торговых агентов.... Нет сейчас таких пользователей, нет таких подсистем и вообще зачем ведут это поле у ряда работников в той конторе непонятно?

Плюнул не логику и просто начал отслеживать происходящее с данными программы при задании этого поля в режиме изменения атрибутов работников и НАКОНЕЦ выявил,. что несмотря на мои попытки вернуться на запись работника перед сохранением много этапные перемещения по таблицам и строкам справочников всё равно позиционировало на руководителя. Тогда просто перед финальным сохранением измененной информации принудительно вставал на правильную запись, что и разрешило "загадку десятилетия".


P.S. Так как давно не выкладывал релизы, то желающие могут увидеть данную проблему в реалиях, но это породит порчу БД. Исправления доступный в релизах после "августа 2022"
24.08.2022 15:07
AndreyZh
 
Прикольная сегодня случилась постановка задачи и … с неожиданной стороны

Как обычно поставил машину на стоянке предприятия, закурил, вдруг с другого места стоянки выезжает фура и запирает меня. Подумал, что встал на погрузку и пошел "по рукам". В кабинет операторов вваливается несколько водителей весьма агрессивного вида вместе с их начальником, окружая меня, что бы не сбежал и начинают тыкать стопками бумажек одновременно, что-то объясняя. Наконец-то понял, но удивился сроку в течении которого они "доходили" до осознания неудобства - формы документов опера делают с начала мая.

Суть: в первичке печатается крупным шрифтом наименование КА и адрес доставки, дабы полуслепые водители при любом освещении могли знать куда вести товар, компактные формы так же имеют эту добавочную информацию, но прикол в том, что адрес доставки печатается под местом для печати, а печать делает информацию по адресу практически нечитаемой - очевидный эргономический косяк, о котором оказывается водители давно жалуются всем подряд, кроме меня. Ну сейчас переделал, завтра установлю по удаленке:

07.04.2023 15:29
AndreyZh
 
Сижу, как-то у клиента, работу работаю. Рядом буйное обсуждение производственных вопросов среди руководителей, что-то там непонятное "нафига ввели в оборот некую группу товаров"? Обратив внимание на меня задали вопрос, а как в программе "УС Лэнд" можно понять насколько разумным было начать работу с данной новой группой товаров? Система не могла дать понятного и чёткого прямого ответа на вопросы такого типа, но "выкрутился" через неудобные многоходовые аналитические механизмы, что впрочем было не совсем корректно, т.к. это давало "слепок" деятельности, а бизнес - это живой динамичный организм... Поспрошал и у других пользователей системы на предмет "поломать голову" на этой задачкой... В ответ - конечно надо, но врятли это анализируемо. Думал, думал и придумал... Суть: разделить обороты по разным наборам товаров и сравнить динамику оборотов в схожих периодах.

Задача действительно важная, т.к. ввод в оборот принципиально новых товаров (продукции) может:

1. Повысить общую эффективность бизнеса;
2. "Съесть" продажи "старых" групп товаров;
3. Ухудшить бизнес, т.к. покупатели "растерявшись" в обилии номенклатуры будут хуже покупать всё

Добавил в контур "динамической" отчетности: https://olegon.ru/showthread.php?t=19149 новый отчётик:





Запросы:

1. Стартовая дата анализа. Не обязательна она должна коррелироваться со стартом ввода в оборот нового, а иногда лучше "расширить горизонты"
2. Длину подпериода в днях, где 0-помесячно. Сравниваются продажи минус возвраты в динамике
3. Максимальное число периодов в отчете. На скрине смотрю 12 месяцев
4. Группу новых ассортиментов. Выделяем произвольную номенклатуру, продажи по которой будем сравнивать с продажами остального товара
5. Гр. разделов. Может сравнивать не со всем прайсом, а только в рамках неких его разделов
6. Тип цены закупа для расчета себестоимости и дохода. Напомню, что себестоимость - виртуальный объект системы, где в частности есть и реальная себестоимость или некая цена продажи. Интересно 1-где к реальной себ-ти добавляем затраты, например на доставку или 12, где добавляем общефирменные затраты, отнесенные на единицу готовой продукции
7. Этот блок отчетов имеет кучу форматов вывода и древний, когда "пихали" в файл легко загружаемый в электронные таблицы (сейчас можно напрямую).

Форма вывода. Экспортные формы просто дают данные без округлений, а набор и содержимое колонок одинаково:

Код:
          Влияние ввода в оборот группы(новых) товаров(продукции) на показатели продаж фирмы за период с 01.03.22          Стр.  1
----------------------------------------------------------------------------------------------------------------------------------
ПодпериодВремени|Отг-ВозвГр|Себестоим.|ДоходПоГр.| Кол-во |УПк|УАдр|к ТТН|Отгр-ВВнеГ|Себ-тьВнеГ|Дох.ПоВнеГ| Кол-во |УПк|УАдр|к ТТН
----------------------------------------------------------------------------------------------------------------------------------
Март          22     395017     355563      39453      770  41   13    90   14850134   13716216    1133917    73476 191   66  1457
----------------------------------------------------------------------------------------------------------------------------------
Апрель        22     185575     166426      19149      351  36   11    71   14813548   13976459     837089    61363 175   64  1266
----------------------------------------------------------------------------------------------------------------------------------
Май           22      13370      12056       1314       25   3    1     5   15409246   14584700     824546    60911 174   62  1269
----------------------------------------------------------------------------------------------------------------------------------
Июнь          22      96756      90623       6132      174  12    3    16   12205479   11557639     647840    50778 178   60  1197
----------------------------------------------------------------------------------------------------------------------------------
Июль          22     232812     220956      11856      420  26    7    43   15825051   14916224     908827    64379 160   58  1199
----------------------------------------------------------------------------------------------------------------------------------
Август        22     234290     220837      13452      425  16    5    33   17267839   16301540     966299    69122 153   52  1230
----------------------------------------------------------------------------------------------------------------------------------
Сентябрь      22     342297     342597       -300      681  32    8    67   20058845   18969333    1089513    76613 154   51  1287
----------------------------------------------------------------------------------------------------------------------------------
Октябрь       22     320792     314432       6360      622  29   12    66   18969753   17907051    1062702    66815 148   54  1237
----------------------------------------------------------------------------------------------------------------------------------
Ноябрь        22     471183     447782      23400      879  37    7    73   19145806   18086598    1059208    65357 153   52  1237
----------------------------------------------------------------------------------------------------------------------------------
Декабрь       22     416248     396051      20197      781  28    9    61   19648328   18564995    1083334    74160 154   51  1314
----------------------------------------------------------------------------------------------------------------------------------
Январь        23     338956     318294      20663      625  28    9    62   16075864   15066911    1008953    55530 144   46  1022
----------------------------------------------------------------------------------------------------------------------------------
Февраль       23     322546     305815      16730      602  31    7    64   14710421   13805880     904541    50885 143   41  1016
----------------------------------------------------------------------------------------------------------------------------------
ИтогЗаВесьПериод    3369841    3191433     178407     6356                 198980316  187453547   11526769   769390
Нуждается в пояснении и давшее наибольшие сложности при разработке отчета:

УПк - число уникальных контрагентов в периоде
УАдр - число уникальных адресов доставок (магазинов) в периоде. У этой конторы ведут адреса только для сетевых магазинов, т.е. адресов меньше, чем КА
кТТН - число накладных отгрузочных + возвратных
10.02.2024 08:37
AndreyZh
 
Конечно - это более подходит для "контура производства": https://olegon.ru/showthread.php?t=10401, но показалась весьма "занятной" и сложной задачей... Выявилась бизнес-заморочка:

Производство и развоз работает круглосуточно, а операторы и бухгалтера только в рабочие дни с 8:00 до 18:00. Зачастую на момент завершения смены точно не известно какое количество продукции будет вывезено после 18:00 и до 8:00, а максимум до 9:00 необходимо оформить факты производства по всем этапам производства готовых изделий, сформировать и отослать покупателям отгрузочные документы и акты сверок для требования перечисления средств, да и фоном оформить новые заявки... то есть с 8:00-9:00 "полный абзац"!

Как придумали пользователи? Они по системе "производят продукцию" и размещают на складе СГД с смену, предшествующую "дурдому" с некоторым запасом, т.е. с утра, используя автоматические режимы создания документов, режимы пакетной печати комплектов документов всё легко успевают сделать. Однако иногда придя утром узнают, что что-то не смогли произвести или развести по тем или иным причинам... и тогда им приходится несколько часов "откатывать" производство по всей цепочки до сырья... Редко, когда под ноль, а в основном куча манипуляций и инвентаризациям, фиктивными производствами и т.д. Попросили меня в этом пособить!

Создал новый режим "частичного удаления производства", благ алгоритмы имелись:





но выявилось куча "заморочек", связанная с расширенными возможностями системы, которые сейчас не используются, но процессы на это заточены:

1. Допустимость производства по нетто или брутто;
2. Списание технологических потерь;
3. Округления "пограничных" значений и etc... На что и убил целую неделю, но вроде бы всё работает без проблем и узеры весьма довольны
Часовой пояс GMT +3, время: 17:31.

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