Занятные замечания по программам семейства УС Лэнд от реальных пользователей : КИС Lack & УС Land
21.11.2024 15:10
█ 21.04.2022 11:31
Зачастую пользователи обращаются с нестандартными вопросами или запросами, а иногда замечают ошибки в программах, исправления которые приводят к обнаружению "нежданчиков" и глобальной переделки системы... Вот, например недавно присланный скрин с вопросом - как такое могло произойти?
… и одна из глобальных проблем, выявленных при анализе скрина. Выявлено, т.к. обычно использую данные от пользователей просто для отладки нюансов программы, а "вне" этих нюансов данные не анализирую, а посему иногда получаются такие неожиданности.
Последний код документа == ZVMU, т.е за время работы фирмы с программой было создано более 1.7млн безналичных операций и счетчик документов - уникальных кодов уже очень близко к пределу == ZZZZ (36-ричное число). Удивительно, т.к. голова забита другими задачами, но вспомнил, что уже предполагал у них такую ситуацию и в версии 2112 системы продумал и сделал перекодировку счетчика по данным типам документов в программа hLv... Ну а дальше, когда все ушли с работы автоматом преобразовал коды и получилось:
… но это была лишь одна прблемища выявленная на скрине => продолжение следует
… и одна из глобальных проблем, выявленных при анализе скрина. Выявлено, т.к. обычно использую данные от пользователей просто для отладки нюансов программы, а "вне" этих нюансов данные не анализирую, а посему иногда получаются такие неожиданности.
Последний код документа == ZVMU, т.е за время работы фирмы с программой было создано более 1.7млн безналичных операций и счетчик документов - уникальных кодов уже очень близко к пределу == ZZZZ (36-ричное число). Удивительно, т.к. голова забита другими задачами, но вспомнил, что уже предполагал у них такую ситуацию и в версии 2112 системы продумал и сделал перекодировку счетчика по данным типам документов в программа hLv... Ну а дальше, когда все ушли с работы автоматом преобразовал коды и получилось:
… но это была лишь одна прблемища выявленная на скрине => продолжение следует
█ 26.04.2022 08:05
Продолжение - окончание:
Изначально, где видны все проблемы было в письме со скрином:
Проблема была сложной для понимания, т.к. задающий вопрос не помнил, как это сделала? Следовательно нужно было найти способ, как её повторить. В программе есть много способов привязать оплаты к накладным, что даёт возможности для многих аналитик, хотя с позиции "аналитики" привязки не обязательны. Перепробовал все способы, например, когда задаём сумму платежа, а программа сама автоматом подбирает накладные для привязки:
Всё работало чётко, пока не "нащупал"... В списке накладных для оплаты (привязки) можно для самоконтроля задать общую сумму платежа и ручками подобрать под неё накладные, а программа просто контролирует, что бы сумма по отобранным ТТН не превысила заданную.
Хвост оплаты создаёт отдельный непривязанный к ТТН платеж. Так вот, если указать сумму точно равную подобранным ТТН, программа создавала липовый документ с нулевой суммой. Осталась "последняя" загадка - почему привязан нулевой платеж к накладной?
Оказалось, что программа честно и тупо отражала список накладных с непривязанным хвостом меньше или равным нулевой сумме финансового документа, т.е. полностью оплаченных и к ним можно было привязать нулевую сумму в режиме «^ -> Связать с товарно-транспортной накладной»... Исправил эту некритичную ситуацию заблокировав привязку нулевых сумм и отбор полностью оплаченных накладных.
Изначально, где видны все проблемы было в письме со скрином:
Проблема была сложной для понимания, т.к. задающий вопрос не помнил, как это сделала? Следовательно нужно было найти способ, как её повторить. В программе есть много способов привязать оплаты к накладным, что даёт возможности для многих аналитик, хотя с позиции "аналитики" привязки не обязательны. Перепробовал все способы, например, когда задаём сумму платежа, а программа сама автоматом подбирает накладные для привязки:
Всё работало чётко, пока не "нащупал"... В списке накладных для оплаты (привязки) можно для самоконтроля задать общую сумму платежа и ручками подобрать под неё накладные, а программа просто контролирует, что бы сумма по отобранным ТТН не превысила заданную.
Хвост оплаты создаёт отдельный непривязанный к ТТН платеж. Так вот, если указать сумму точно равную подобранным ТТН, программа создавала липовый документ с нулевой суммой. Осталась "последняя" загадка - почему привязан нулевой платеж к накладной?
Оказалось, что программа честно и тупо отражала список накладных с непривязанным хвостом меньше или равным нулевой сумме финансового документа, т.е. полностью оплаченных и к ним можно было привязать нулевую сумму в режиме «^ -> Связать с товарно-транспортной накладной»... Исправил эту некритичную ситуацию заблокировав привязку нулевых сумм и отбор полностью оплаченных накладных.
█ 18.07.2022 14:38
Сегодня разрешилась "загадка десятилетия" для системы "УС Land"! Ура!!!
Более десяти лет периодически, примерно раз в 3-5 месяцев, возникала неприятная ситуация. Появлялась полностью дублированная запись по работнику и исчезал из справочника руководитель предприятия, ссылка на которого имеется во всех типах документов. Это было удивительно, т.к. ошибка появлялась только у одного клиента и абсолютно непредсказуемым образом. Конечно она несложно исправлялась, но руководителю каждый раз приходилось заполнять свои реквизиты, т.е. инфа о косяках в работе программы каждый раз доходила до него.
Причина пыталась каждый раз найтись, но безуспешно - небольшая таблица простой структуры, редко изменяемая по сети. Десятки раз мной изучался и переписывался код с целью не допустить её в последующем. Единственный эффект - она стала гораздо реже появляться. Более того один раз уже в состоянии "истерики" выставил бутылку дорого вина перед 4 очень умными операторами для того, кто ошибку сможет воссоздать... Всё тщетно - они меня уже успокаивали, что она особо на работу не влияет, да и возникает крайне редко...
Сегодня она появилась снова.На удачу - оператор сделал минимум операций в программе и запустил проверку логики, а посему запомнил, что лишь у водителя, который появился в дубле она изменила атрибуты водительского удостоверения... и больше ничего. Как обычно по удаленке убрал дубль, руководитель, как обычно снова занес свои реквизиты... и через пару минут снова дубляж этого водятла появился.
Снова восстановил данные, но пока не нагружая начальника попросил ещё раз проверить изменение строки справочника... медленнее... и тут до меня "доходит", что код руководителя указывается в карточке работника. Меняю карту другого работника, у которого нет руководителя - дубляжа не даёт. Меняю карту у "злополучной" записи, но удаляю код руководителя - не даёт дубляжа... Пока говорю при изменении карты стирать ненужный код руководителя и начинаю изучения у себя в тестовой БД. Злополучный атрибут есть на скрине:
В сотый раз изучаю код - всё "чисто". Начинаю вспоминать - нафига нужен этот атрибут. Вспомнил - более 15 лет назад в систему были введены 100% "кадры", а потом их удалил, а так же это поле использовалась при работе с автозаказами от торговых агентов.... Нет сейчас таких пользователей, нет таких подсистем и вообще зачем ведут это поле у ряда работников в той конторе непонятно?
Плюнул не логику и просто начал отслеживать происходящее с данными программы при задании этого поля в режиме изменения атрибутов работников и НАКОНЕЦ выявил,. что несмотря на мои попытки вернуться на запись работника перед сохранением много этапные перемещения по таблицам и строкам справочников всё равно позиционировало на руководителя. Тогда просто перед финальным сохранением измененной информации принудительно вставал на правильную запись, что и разрешило "загадку десятилетия".
P.S. Так как давно не выкладывал релизы, то желающие могут увидеть данную проблему в реалиях, но это породит порчу БД. Исправления доступный в релизах после "августа 2022"
Более десяти лет периодически, примерно раз в 3-5 месяцев, возникала неприятная ситуация. Появлялась полностью дублированная запись по работнику и исчезал из справочника руководитель предприятия, ссылка на которого имеется во всех типах документов. Это было удивительно, т.к. ошибка появлялась только у одного клиента и абсолютно непредсказуемым образом. Конечно она несложно исправлялась, но руководителю каждый раз приходилось заполнять свои реквизиты, т.е. инфа о косяках в работе программы каждый раз доходила до него.
Причина пыталась каждый раз найтись, но безуспешно - небольшая таблица простой структуры, редко изменяемая по сети. Десятки раз мной изучался и переписывался код с целью не допустить её в последующем. Единственный эффект - она стала гораздо реже появляться. Более того один раз уже в состоянии "истерики" выставил бутылку дорого вина перед 4 очень умными операторами для того, кто ошибку сможет воссоздать... Всё тщетно - они меня уже успокаивали, что она особо на работу не влияет, да и возникает крайне редко...
Сегодня она появилась снова.На удачу - оператор сделал минимум операций в программе и запустил проверку логики, а посему запомнил, что лишь у водителя, который появился в дубле она изменила атрибуты водительского удостоверения... и больше ничего. Как обычно по удаленке убрал дубль, руководитель, как обычно снова занес свои реквизиты... и через пару минут снова дубляж этого водятла появился.
Снова восстановил данные, но пока не нагружая начальника попросил ещё раз проверить изменение строки справочника... медленнее... и тут до меня "доходит", что код руководителя указывается в карточке работника. Меняю карту другого работника, у которого нет руководителя - дубляжа не даёт. Меняю карту у "злополучной" записи, но удаляю код руководителя - не даёт дубляжа... Пока говорю при изменении карты стирать ненужный код руководителя и начинаю изучения у себя в тестовой БД. Злополучный атрибут есть на скрине:
В сотый раз изучаю код - всё "чисто". Начинаю вспоминать - нафига нужен этот атрибут. Вспомнил - более 15 лет назад в систему были введены 100% "кадры", а потом их удалил, а так же это поле использовалась при работе с автозаказами от торговых агентов.... Нет сейчас таких пользователей, нет таких подсистем и вообще зачем ведут это поле у ряда работников в той конторе непонятно?
Плюнул не логику и просто начал отслеживать происходящее с данными программы при задании этого поля в режиме изменения атрибутов работников и НАКОНЕЦ выявил,. что несмотря на мои попытки вернуться на запись работника перед сохранением много этапные перемещения по таблицам и строкам справочников всё равно позиционировало на руководителя. Тогда просто перед финальным сохранением измененной информации принудительно вставал на правильную запись, что и разрешило "загадку десятилетия".
P.S. Так как давно не выкладывал релизы, то желающие могут увидеть данную проблему в реалиях, но это породит порчу БД. Исправления доступный в релизах после "августа 2022"
█ 24.08.2022 15:07
Прикольная сегодня случилась постановка задачи и … с неожиданной стороны 
Как обычно поставил машину на стоянке предприятия, закурил, вдруг с другого места стоянки выезжает фура и запирает меня. Подумал, что встал на погрузку и пошел "по рукам". В кабинет операторов вваливается несколько водителей весьма агрессивного вида вместе с их начальником, окружая меня, что бы не сбежал и начинают тыкать стопками бумажек одновременно, что-то объясняя. Наконец-то понял, но удивился сроку в течении которого они "доходили" до осознания неудобства - формы документов опера делают с начала мая.
Суть: в первичке печатается крупным шрифтом наименование КА и адрес доставки, дабы полуслепые водители при любом освещении могли знать куда вести товар, компактные формы так же имеют эту добавочную информацию, но прикол в том, что адрес доставки печатается под местом для печати, а печать делает информацию по адресу практически нечитаемой - очевидный эргономический косяк, о котором оказывается водители давно жалуются всем подряд, кроме меня. Ну сейчас переделал, завтра установлю по удаленке:
Как обычно поставил машину на стоянке предприятия, закурил, вдруг с другого места стоянки выезжает фура и запирает меня. Подумал, что встал на погрузку и пошел "по рукам". В кабинет операторов вваливается несколько водителей весьма агрессивного вида вместе с их начальником, окружая меня, что бы не сбежал и начинают тыкать стопками бумажек одновременно, что-то объясняя. Наконец-то понял, но удивился сроку в течении которого они "доходили" до осознания неудобства - формы документов опера делают с начала мая.
Суть: в первичке печатается крупным шрифтом наименование КА и адрес доставки, дабы полуслепые водители при любом освещении могли знать куда вести товар, компактные формы так же имеют эту добавочную информацию, но прикол в том, что адрес доставки печатается под местом для печати, а печать делает информацию по адресу практически нечитаемой - очевидный эргономический косяк, о котором оказывается водители давно жалуются всем подряд, кроме меня. Ну сейчас переделал, завтра установлю по удаленке:
█ 07.04.2023 15:29
Сижу, как-то у клиента, работу работаю. Рядом буйное обсуждение производственных вопросов среди руководителей, что-то там непонятное "нафига ввели в оборот некую группу товаров"? Обратив внимание на меня задали вопрос, а как в программе "УС Лэнд" можно понять насколько разумным было начать работу с данной новой группой товаров? Система не могла дать понятного и чёткого прямого ответа на вопросы такого типа, но "выкрутился" через неудобные многоходовые аналитические механизмы, что впрочем было не совсем корректно, т.к. это давало "слепок" деятельности, а бизнес - это живой динамичный организм... Поспрошал и у других пользователей системы на предмет "поломать голову" на этой задачкой... В ответ - конечно надо, но врятли это анализируемо. Думал, думал и придумал... Суть: разделить обороты по разным наборам товаров и сравнить динамику оборотов в схожих периодах.
Задача действительно важная, т.к. ввод в оборот принципиально новых товаров (продукции) может:
1. Повысить общую эффективность бизнеса;
2. "Съесть" продажи "старых" групп товаров;
3. Ухудшить бизнес, т.к. покупатели "растерявшись" в обилии номенклатуры будут хуже покупать всё
Добавил в контур "динамической" отчетности: https://olegon.ru/showthread.php?t=19149 новый отчётик:
Запросы:
1. Стартовая дата анализа. Не обязательна она должна коррелироваться со стартом ввода в оборот нового, а иногда лучше "расширить горизонты"
2. Длину подпериода в днях, где 0-помесячно. Сравниваются продажи минус возвраты в динамике
3. Максимальное число периодов в отчете. На скрине смотрю 12 месяцев
4. Группу новых ассортиментов. Выделяем произвольную номенклатуру, продажи по которой будем сравнивать с продажами остального товара
5. Гр. разделов. Может сравнивать не со всем прайсом, а только в рамках неких его разделов
6. Тип цены закупа для расчета себестоимости и дохода. Напомню, что себестоимость - виртуальный объект системы, где в частности есть и реальная себестоимость или некая цена продажи. Интересно 1-где к реальной себ-ти добавляем затраты, например на доставку или 12, где добавляем общефирменные затраты, отнесенные на единицу готовой продукции
7. Этот блок отчетов имеет кучу форматов вывода и древний, когда "пихали" в файл легко загружаемый в электронные таблицы (сейчас можно напрямую).
Форма вывода. Экспортные формы просто дают данные без округлений, а набор и содержимое колонок одинаково:
Нуждается в пояснении и давшее наибольшие сложности при разработке отчета:
УПк - число уникальных контрагентов в периоде
УАдр - число уникальных адресов доставок (магазинов) в периоде. У этой конторы ведут адреса только для сетевых магазинов, т.е. адресов меньше, чем КА
кТТН - число накладных отгрузочных + возвратных
Задача действительно важная, т.к. ввод в оборот принципиально новых товаров (продукции) может:
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
Конечно - это более подходит для "контура производства": 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... На что и убил целую неделю, но вроде бы всё работает без проблем и узеры весьма довольны
Выявилась бизнес-заморочка:Производство и развоз работает круглосуточно, а операторы и бухгалтера только в рабочие дни с 8:00 до 18:00. Зачастую на момент завершения смены точно не известно какое количество продукции будет вывезено после 18:00 и до 8:00, а максимум до 9:00 необходимо оформить факты производства по всем этапам производства готовых изделий, сформировать и отослать покупателям отгрузочные документы и акты сверок для требования перечисления средств, да и фоном оформить новые заявки... то есть с 8:00-9:00 "полный абзац"!
Как придумали пользователи? Они по системе "производят продукцию" и размещают на складе СГД с смену, предшествующую "дурдому" с некоторым запасом, т.е. с утра, используя автоматические режимы создания документов, режимы пакетной печати комплектов документов всё легко успевают сделать. Однако иногда придя утром узнают, что что-то не смогли произвести или развести по тем или иным причинам... и тогда им приходится несколько часов "откатывать" производство по всей цепочки до сырья... Редко, когда под ноль, а в основном куча манипуляций и инвентаризациям, фиктивными производствами и т.д. Попросили меня в этом пособить!
Создал новый режим "частичного удаления производства", благ алгоритмы имелись:
но выявилось куча "заморочек", связанная с расширенными возможностями системы, которые сейчас не используются, но процессы на это заточены:
1. Допустимость производства по нетто или брутто;
2. Списание технологических потерь;
3. Округления "пограничных" значений и etc... На что и убил целую неделю, но вроде бы всё работает без проблем и узеры весьма довольны
Часовой пояс GMT +3, время: 15:10.
Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.