Сборник технологий универсальной системы УС Land : КИС Lack & УС Land

Новое! При поставке продукции на распределительные центры сетей от нас требуют: каждый товар на отдельной паллете и на паллете наличие паллетной этикетки…

Наконец сделал. Сложности в вариантности требований сетей и небольшого "разгильдяйства", например:

1. Некоторые сети требуют указание наименования продукции "как у них в базе";
2. Заказы делают не кратно объему паллеты и зачастую на ряде паллет нехватка товаров, а другие "наращиваю";
3. Часть атрибутов допускаю, что не ведутся, да и как принято в "УС Land" допускается работа от имени других юридических лиц и так далее.

Посему - вначале производится интерактивная настройка "паллет":





Опосля на принтер через ХБК печатается "настроенная" пачка этикеток по конкретному заказу. Раннее данные формы рисовались и настраивались в электронной таблице для каждой сети. На примере "номер заказа и имя РЦ" не отражается - глюк печати через выгрузку в PDF:

Компьютерное оборудование уже давно не успевает за людьми и "УС Land" и где-то в 2016 была придумана техника пакетной печати
Вызов:





Настраиваются параметры печати:





… и программа выводит сотни листов на печать, причем документы разных типов можно запустить на печать в параллельном режиме, например УПД и ТТН, а в это время персонал дорабатывает принятые автоматом очередную пачку заказов …

Но и этого "фонарика на ..." оказалось руководителю мало и совместно с дамами в марте, апреле придумали ряд механизмов, которые ещё более гибкими делали эти технологии:

1. Паллеты оформляются отдельными документами (УПД), но для них не нужно печатать ТТН и ТН - появился запрос, удаляющий данные доки из печати накладных;

2. См. ниже. В принципе обязательный номер заказа, атрибуты водителя и авто раньше были едиными, задаваемые при "обучении", но в ноябре 2020 появилось обязательное требование передачи в EDI атрибутов водителя + авто для РЦ, т.е. они стали задаваться в БД. Сейчас в "повторе" печати, пакетной печати изменяемые описательные атрибуты выбираются из заказов/накладных





3. Ряд сетей требуют одновременной печати ТТН и ТН, которые программа различает наличием "описания груза". Как всегда придумана "обманка" для программы - если в задании пакета указать одновременную печать, то программа, как бы вначале стирает "описания груза", т.е. печатается ТТН, а затем восстанавливает его, т.е. печатается нужный документ и если этот параметр был, то ТН.

Ещё одна реинкарнация древней технологии системы, которая вдруг оказалась востребованной

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

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

- при приёме по EDI, если цена товара меньше, чем цена прайса покупателя, то в "признаке" предзаказа проставлялся знак "А";
- добавлен отчет в "предзаказах", где отделялись поставки по акциям от обычных....

Как выяснилось сейчас - этой техникой не стали пользоваться, т.к., по "объяснениям", по EDI приходят пока 20% заказов, а остальные в виде электронных таблиц (другие программы) или вводят "ручками"... а выяснилось, когда "в полный рост" выявилась проблема 2021 года: происходит постоянное изменение цен на сырьё, фрагментарный рост цен на продукцию, по разному, для разных сетей и всё это "накладывается" на постоянные, проводимые по разным сетям, разным регионам, разным группам товаров акциям… в итоге выяснилось, что ответственные лица частично потеряли ориентацию в ценовой политике и марже?

Передо мной поставлена задача - что-нибудь придумать, а лучше "вчера", что-бы сделать картину с ценами прозрачной для анализа и планирования. Это действительно проблема, т.к. прайсы постоянно меняются, цены для всех ТС разные, а программа хранит лишь историю цен по реальным отгрузкам и сличать их не с чем.

… и опять вспомнилась древня "эта" техника но "расширилась" в свежей реинкарнации:

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




Программа всегда имела развитые технологии группирования своих объектов в пачки, например заказы можно отделить по нескольким юридическим лицам ТС и региону, где проводится акция:




После производства продукции, а по факту изначально производится, отгружается продукция по заказам и певички, печатаемой по ней, а лишь на следующий день создаются отгрузки и отправляются документы в EDI. Из предзаказов накладные получаются автоматическим "распределением", где все товарные признаки из заказов переходят на накладные. Модифицирован основной отчёт (18 форматов для разных целей) по отгрузке, где сейчас можно отделять продажи по акциям от прочих видов продаж:




… пока идёт процесс "привыкания" всего персонала к "новой" технике, а дальше "поживём - увидим" ...

Технология групп программ семейства "УС Лэнд" - это метод заставить программу считать произвольный набор объектов (элементов справочников, документов), как один (любые объекты программы). От рождения системы признаком отнесения к группе является логическое поле dGr, имеющееся во всех таблицах БД... и манипуляция этим признаком - анализ или изменение данного поля. Понятно, что всё реализовано в библиотеке функций системы и работает единообразно для любых списков.

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

Замечания и предъявы мне озвучивают давно, но решение данной проблемы:

1. Придумать удобную и быструю замену техник;
2. Только для предзаказов переделать около 100 режимов... ну и создать библиотеку новых режимов.





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

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

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


P.S. На скрине отмечено разделение, раннее ошибочно совмещенными в одном режиме разные виды изменения заказов, что вызывало путаницу у пользователей

Пришлось вспоминать старое и устоявшееся

В системе "УС Лэнд" деньги ведутся, анализируются по трем типам мест:

1. Неограниченное число касс для регламентного контроля наличных средств;
2: Неограниченное число расчетных счетов (банков) для работы с безналичными средствами;
3. Так называемый "сейф" - деньги владельца бизнеса, находящиеся где-то.

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





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

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

1. Движение по сейфу, как через кассы, так и через расчетные счета;
2. Неограниченное число "сейфов".

Для этого переделаны все:

1. Режимы ведения денежных средств через "сейфы":
2. Все аналитики и контролы по "сейфу" учитывают все нюансы его ведения;
3. Не смог... и при обнулении БД все "сейфы" программа сводит к одному "сейфу"... и только "наличные".

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





Жизнь заставляет постоянно бизнес (и меня) заниматься прогнозированием, а для этого часть искусственной подделки данных приходилось делать в ручную по удаленке… и практически ежедневно. Записал себе задачу - найти способ передать это в компетенцию пользователей, а в "запарке" забыл о древней технологии, которая впрочем, как убедился вспоминая является слишком сложной.

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




Изменения производятся для произвольного, подобранного множеством способов набора объектов (группы) - звёздочки справа. Старые техники по пунктам режима. Если что непонятно - задавайте вопросы













… и сегодня придумал и реализовал максимально упрощенную, но достаточную для актуальных задач технику:






Что за "гемор" был до недавнего времени?

1. По удаленке через системную утилиту правил нужные виртуальные цены в справочнике:





2. Затем по технике прямого изменения полей таблиц (справочников) оператор доделывал виртуальные цены по нужному сырью... Правда он уже наименования полей БД знает лучше меня

При разработке: https://olegon.ru/showthread.php?t=36634 возник вопрос об облегчении труда операторов при синхронизации данных объектов системы с данными, имеющимися в еУПД??? Конечно и вначале создал механизмы ввода каждого атрибута через копипаст, но решил, что заполнять десятки полей справочника будет утомительно... и придумал...

По данным из УПД перед вводом создаётся контейнер, содержащий всю полезную инфу из УПД, как в другом примере: 771 # 0000000-771001001 # # 7710000000 # 771001001 # ООО Василек # 643,123310,77,,Москва,,Березовая,10,, - его копируем Ctrl+C, а при создании/обновлении объектов УС - его вставляем Ctrl+V, а режим анализа контейнера разлагает его по разным полям ввода, которые можно исправлять





… потом, обдумывая вопрос: https://olegon.ru/showpost.php?p=384092&postcount=82 понят и примерно спроектировал новую глобальную технику закачки куда угодно в систему из чего угодно... осталось найти время на набивания текста процедуры

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

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





1. Такой настройки вообще нет в программе, а счета/фактуры имеют формат, зависящий от даты документа. Исходно - напечатать пачку УПД в "промежуточном" формате... Просто когда-то их напечатали в неверном формате (была протухшая ХБК), а сейчас надо доки переоформить именно в том виде;

2. Здесь замещается глобальная настройка.... Иногда надо ответственному товарищу для ответственных госорганов перепечатать гору реальных и липовых документов за прошлые периоды, а "светить", что доки только что сделаны нельзя.


P.S. Понятно, что это пока лишь прототип под разнообразные последующие доработки... и решение насущных задач сей момент

Продолжаются, начавшиеся с 1 января, новогодние каникулы

Сегодня с утречка по удаленке делал нуление БД у одного из пользователей. В терминах "1С" - это обрезание БД. Зачем его делают? Раньше предполагал, что при её больших размерах программа работает менее стабильно, да и отчеты строятся очень долго ("тяжелые" до 5 минут). Что понимать под большим размером - в "УС Лэнд" смотрю на число операций в таблице истории всех операций, а максимальное "на памяти" было около 2.5 млн, сегодня всего около 0.5 млн - мизер. Размер БД при этом 380Мб. Для примера в одно время обрезалась и 1С:Бухгалтерия того же предприятия, но размер её БД на сейчас 18Гб... Озвученная причина нуления - уже привыкли резать ежегодно, да и специфика бизнеса 2023 будет радикально отличаться от 2022, т.е. анализ (сравнения) этих годов будет похож на сравнения теплого и мягкого...

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





Как пример... После этого нуления, при сохранении неоплаченных приходов, отгрузок осталось около 20.000 операций, а размер БД уменьшился до 40Мб

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

1. Нашей учетной системой;
2. Государственными сервисами;
3. Частными провайдерами;
4. Учетными системами поставщиков и покупателей

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

Вот и уже давно в системе стали появляться механизмы, помогающие избегать эти конфликты, а именно - подбора цен, так что-бы при применении НДС, цены с НДС и цены без НДС получались с округлениями - это и автопроставление цен в прайсах, выписка отгрузок с полуавтоматической подгонкой цен, сервис проверки цены и так далее. Число разборок с контрагентами уменьшилось в десятки раз. Однако и изредка появляются расхождения, связанные с проведением акций: https://olegon.ru/showthread.php?t=37806 и эти проблемы проявляются постфактум, т.е. когда документы ушли в работу и это порождает необходимость их переделки...

Придумана технология избежать отправки кривых документов в ЭДО/EDI, проверив их пачку на "корректность" цен. Во всех типах товарных документов внедрен режим, вызываемый из меню или нажатием кнопки, в котором проверяется все или группа документов за период времени:





Вопросы привычные:





В результате программа даёт справку по данным (ценам не дающим ошибок округления), которой можно подправить конкретные документы