Верификация внутренних данных в универсальной учетной системе "УС Land" : КИС Lack & УС Land

AndreyZh · █ 20.01.2020 08:43

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

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

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

На выходе получается отчет - результат проверки... а далее используют средства программ для корректного изменения операция с дублированными клиентами и их удаления из справочника:

Код:


Поиск дублей клиентов по ИНН на 20.01.20
----------------------------------------------------------------------------------------------------------------------------------
Непустой ИНН|Наименование первого по имени клиента с данным ИНН|КодК|Наименование дублированного по номеру ИНН клиента |КодК|Прим.
----------------------------------------------------------------------------------------------------------------------------------
7303001609    Актом АО                                          030B  Актом ЗАО                                         01SM
----------------------------------------------------------------------------------------------------------------------------------
6453135617    СарПласт ТД ООО                                   02XE * СарПласт ТД ООО                                  0125
----------------------------------------------------------------------------------------------------------------------------------
644901100440  Интекс-Стайл ООО                                  02OR *ООО Эклипс                                        02I7
.....

AndreyZh · █ 14.02.2020 09:51

Предполагаю, что в данной теме буду размещать лишь новый режимы верификации или существенное изменение старых, а все основные можно будет увидеть на скрине

Периодически в большом магазине - около 6000 уникальных наименований алкоголя и БД "тащится" с 2012 года, возникает проблема, что "Фронтол" или "УСЕга" неверно находит товар по ШК EAN-13… проблема очевидна - дубли ШК, которые в спешке допускают продавцы при оприходовании алкоголя и даже делал, описывал технику поиска дублей в справочнике.

Оказывается "забыл" о древнем режиме поиска дублей ШК у разноименных товаров, который создал в 2004 году, когда впервые внес техники продаж по ШК в систему. Построили отчет - оказалось 60 страниц, где большинство товаров уже закончилось и закупаться не будут.

С утречка поменял алгоритмы, формы, ограничители данного режима верификации... и что получилось:

Новая печатная форма отчета - старую можно увидеть в текущей версии:

Код:

Отчет по поиску дублированных штрих кодов Стр. 4
----------------------------------------------------------------------------------------------------------------------------------
Штрих код тов| Наименование товара |КодА| Наименование товара с дублем штрихкода |ОстПоВсемСк
----------------------------------------------------------------------------------------------------------------------------------
9311789081847 Яламба Буш Вайн Гренаш 2015г. 0,75л кр.сух. 0CZ6 Яламба Буш Вайн Гренаш 2014г. 0,75л кр.сух. 1.000
----------------------------------------------------------------------------------------------------------------------------------
9311789081847 Яламба Буш Вайн Гренаш 2013г. 0,75л кр.сух. 0D9P Повторные дубли штрихкодов
----------------------------------------------------------------------------------------------------------------------------------
9311789081847 Яламба Буш Вайн Гренаш 2014г. 0,75л кр.сух. 0D9Q Повторные дубли штрихкодов
----------------------------------------------------------------------------------------------------------------------------------
9320909001306 Кейнетон Эстейт Эуфониум 2012г кр.сух. вино 0,75л 0CD0 Кейнетон Эстейт Эуфониум 2013г кр.сух. вино 0,75 1.000
----------------------------------------------------------------------------------------------------------------------------------
9320909001306 Кейнетон Эстейт Эуфониум 2013г кр.сух. вино 0,75л 0D9N Повторные дубли штрихкодов
----------------------------------------------------------------------------------------------------------------------------------

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

AndreyZh · █ 25.03.2020 15:01

Исходно проверки данных и их взаимосвязи располагались в блоке программы «администратор» системы «УС Land», где продолжает в основном данный контур развиваться, из «свежего» все его формы могут экспортироваться в XLS файлы и лишь недавно стал важные проверки ошибок операторов размещать в «оперативной» программе.

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

Рассмотрим один из «древних» режимов, где в версии 2004 добавлено отслеживание и междускладских накладных. Круг задач ограничен Вашей фантазией и они Вам доступны, т.к. учет в системе партиционный, т.е. программой отслеживаются все движения по партиям – кодам товаров и других объектов учета. На память решались задачи:

- Отследить, кому отгрузили возвраты брака вместо утилизации;
- Кому продали товар, поступивший по конкретному заказу;
- От кого пришел товар, для подбора документов по расходной накладной, по которой возникли «вопросы» контролирующих органов и etc…

Из задач «на злобу дня» можно придумать – куда отправлен товар принимаемый зараженным кладовщиком для последующего его изъятия с торговой точки и дезинфекции… Вводим тип отслеживаемой накладной, а именно всех товаров и продукции из неё и её системный код, тип накладных по которым ушел/пришел товар, ограничив при необходимости контрагентом. На выходе получаем форму отчета:

Код:

                               Анализ связи накладной 27FS по товарам с другими накладными.                                Стр.  1
----------------------------------------------------------------------------------------------------------------------------------
КодТ         Наименование товара исходной ТТН           ЦенаТовара Кол - во       Сумма
    ------------------------------------------------------------------------------------------------------------------------------
    ДатаНак.    Номер     КодН          Наименование и системный код клиента           Отср. Опл Т ЦенаТовара Кол - во СуммаПоТов.
----------------------------------------------------------------------------------------------------------------------------------
56SP   С*пирожное "Профитроли шоколад"                       21.80      230     5014.00
    24.02.20 21530        KZ8Y АО "Тандер" ГМ                                     0122 20.03 б/н *      **.69        5      ***.45
    27.02.20 22086        KZX2 Агроторг ООО                                       01DS 24.03 б/н *      **.84        6      ***.04
    28.02.20              L0RH Акулов Владимир Викторович                         01V7 28.02 нал *      **.00        1       **.00
...
56SO   С*пирожное "Эклер со сливками"                        20.85      370     7714.50
    25.02.20 21290        KZ97 ООО "Лента"                                        01QV 20.03 б/н *      **.66       20    *****.20
...    
    26.02.20 22030        KZRS Радеж ООО                                          01L1 29.03 б/н *      **.90       10      **9.00
    27.02.20 22585        L08Q АО "Гулливер"                                      025Z 23.03 б/н *      **.39       14      ***.46
    27.02.20 22514        L06Z Перекресток Торговый дом АО                        01DT 24.03 б/н *      **.72        9      ***.48

AndreyZh · █ 05.02.2022 10:05

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

Сроки годности, даты поступления. Дата прихода партии может указываться в карточке партии товаров, а может и нет, однако в отчетах программа анализирует для определения этого атрибута:

1. Дату приходной ТТН и/или;
2. Дату производства изделия/полуфабриката

Причём допустим, для ряда бизнесов, несколько приходов одной партии. Сроки годности могут необязательно задаваться:

1. Как конкретная дата в карте партии - в основном для сырья или товаров для перепродажи;
2. Срок хранения в днях - в основном для скоропорта или готовых изделий.

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

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

1. Приход одной партии в разных датах;
2. Неверное задание или вообще не задание срока годности;
3. Неверное ведение срока хранения и etc

Код:

                           Анализ сроков годности товаров, сырья, изделий на 05.02.22 10:06:11                             Стр.  1
----------------------------------------------------------------------------------------------------------------------------------
КодТ|                Наименование товара               |ПервПрих|ПоследПр|Рас|СрХранен|ОстНаВсехСкл|Арх|ДнХ|ХранимДо|Исп|Примечан.
----------------------------------------------------------------------------------------------------------------------------------
5MU2 Ароматизатор пищевой "Лесной Орех"                 31.12.21 31.12.21     19.04.19 10000.000000     999 25.09.24    
5ZUE ИЗИ Вивакейк (бисквитная смесь)                      .  .     .  .         .  .       0.000800     999 00.00.00 ***
5HOV Кокосовая стружка Медиум                           31.12.21 31.12.21     03.03.21     0.507000     999 25.09.24    
5YWN Лимонная кислота                                   08.12.21 31.12.21 *** 20.07.20 11675.531500     999 02.09.24    
60NB Сорбат кали ГРАНУЛЫ                                25.01.22 25.01.22     04.05.21 16100.595200     999 20.10.24

Напомню, что система "УС Land", как правило считает значения для "дней" или чисел, равные 0 или 999, как параметр для игнорирования или бесконечный, а для даты - это или пустое значение или 31.12.2099 (срок окончания жизненного цикла системы "УС Land"

)

AndreyZh · █ 17.11.2023 11:32

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

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

1. Проверяет данные;
2. Диагностирует и автоматом пытается исправить около 50% видов ошибок;
3. Предлагает сделать сохранение логически целых данных или сообщает о наличии ошибок, формируя и автоматически сохраняя лог проверки

После сообщения

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

Код:

                                                                                                                      Страница   1
***** Расчетный остаток для 6J5F =    4000.000 не совпадают с остатками на тек.момент     4001.000
**** На складе 01 для 6J5F р/ост.  4000.000000 не совп.с факт.  4001.000000
* ---------------------------------------------------------------------------------------------------
*    ЕСЛИ ПРОГРАММА ИСПРАВИЛА ЧАСТЬ ФАТАЛЬНЫХ ОШИБОК САМА - ПРОВЕРЬТЕ ПОЖАЛУЙСТА ЛОГИКУ ЗАНОВО!!!
* ---------------------------------------------------------------------------------------------------

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

Его суть: На локальном быстром ПК планировщик ОС запускает командный файл типа:

Код:

attrib *.exe -r
copy x:\usland\*.exe                     *.exe
copy x:\usland\*.ico                     *.ico
copy x:\usland\srepharb.bat              *.bat
copy x:\usland\ls\database\*.dbf 	 ls\database\*.dbf
copy x:\usland\ls.cfg                    *.cfg
call srepharb.bat
hle L

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

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

1. Часть документа пришла после его сохранения в истории;
2. Некоторые операции делаю виртуальные данные с резервированием кода в процессе добавления документа, а вся БД изменяется при его сохранении и т.д.

Посему, в реальной фирме 90% запуска автомата сообщало о фатальных ошибках и ничего не сохраняло, хотя при повторной проверки данные уже были логически правильные... Думал, думал и придумал: при запуске АВТОМАТА программа при обнаружении фатальных ошибок не прекращает работу, а производит повторный рекурсивный самозапуск процесса проверки и уже когда в БД простые ошибки были исправлены, а если и при повторном запуске будут обнаружены ошибки, только тогда сообщает о них