В задаче Бухгалтерия есть понятие аналитик.
У разных счетов их может быт разное количество и
и сами справочники аналитики.
Поэтому их редко помещают в таблицу проводок,
а чаще в реляционную - довесок по ключу проводки
Ну, например, поля nbsprav ( ключ аналитики, например контрагентов) valsprave =ключ контрагента , ну и ключ проводки.
Сплошь и рядом аналитики можно не вводить, а вычислить или на базе суб счета или других имеющихся аналитик.
У нас правила такой конвертации лежат в некой настроечной таблице tabconv
Конвертация по ней работает уже годами, но при покупке чужого бух софта с базой на Оракл
появились проблемы, которые на деле были и в дбф варианте.
Проблемы таковы, что % на 95 это работает. Хотелось бы допилить эти 5%
Я сделал некие формы на фоксе, которые помогают выявить эти проблемы, но исправлять их должен оператор в таблице конвертации . А хотелось бы чтобы уже сразу при вводе в таблицу конвертации все было хорошо.
Это хорошо -вот что.
1 Любая существующая комбинация 5 ти значных счетов, контрагентов и статей производственных затрат всегда конвертировалась в непустую аналитику, и никогда не было неоднозначного
значения аналитик.
Для удаления неоднозначности конвертации авторы Оракл процедур пришили в конце запроса rownum=1 и честно написали в комментарии -подумать потом, но потом так и не наступило.
Ясно, что упомянутое решение может давать совершенно хаотичный результат, то одно значение
аналитики, то другое.Как уже написал, я написал механизм, который позволяет буху понять, где у него может возникнут неоднозначность, но уже постфактум. То есть он должен поправить
таблицу конвертации, и провести перерасчет. Также некие комбинации счетов контрагентов
и счетов производственных затрат при конвертации в другие аналитики могут дать пустые значения.
То есть, в этом случае тоже нужно исправить таблицу конвертации.
Тоже написал софт для отловли таких неопределенных аналитик, но опять таки постфактум.
Пока сохраню пост как есть, а то писать еще много, боюсь потерять до сохранения

И так обозначений n_schet 2 значный счет в таблице конвертации
n_tab - код аналитики или ключ
v_sprav - значение аналитики
d_ht - 2 х значный шаблон по дебету ( может быть пустое)
k_ht - 2 значный счет по кредиту ( может быть пустое)
inn - шаблон инн контрагента , может быть пустой,
если первый символ -, значит за исключением таких контрагентов
Пример, 1234, 3456 контрагенты с ИНН на эти символы, а если пред этим будет стоять
-, то за исключением таких контрагентов.
d_list список номеров счетов от 2 до 5 знаков,
пример, 52,585,9031 - то есть бери проводки, если их дебетовый счет начинается на эти
аналогично для кредита k_list , если в начале списка есть -, это значит за исключением таких счетов
Эти поля могут быть пустыми, если не пусты аналогичные d_ht и k_ht,
или наоборот, эти пустые, а списки не пустые. Но могут быть заполнены обе пары полей
Есть еще 2 поля шаблона статей производственных затрат,
пусть называются spzd, spzk ( 5 знаков) на одну статью
Пример заполнения 345, 2456, 54678
Это значит, возьми проводку , если у нее статья начинается с таких знаков. Аналогично - значит отрицание.
И так, это таблица настройки конвертации, где новые аналитики проводки вычисляются на базе существующих 5 знаков счетов в дебете и кредите, контрагента, если он есть, и 2 статйе затрат, если они есть.
Задача такая
Никакая новая аналитика для проводки не должна быть пустаю
и не должна иметь друзначного толкования , чтобы не писать rownum=1
Тот, кто писал конвертацию в фоксе проблемы дублей не видел, так как использовал
seek, а дальше не проверял, может есть другая подходящая строка таблицы конвертации,
которая даст другое значение аналитики.
С пустой аналитикой особо не заморачивались
Но вся эта конвертация используется для отчетности на верх,
пустота плохо, неоднозначность плохо.
Сейчас у меня есть 2 формы, которые ловят обе ситуации, но постреори уже после конвертации.
Хотелось бы это приладить прямо на форме ввода таблицы конвертации.
Тут я вообще не понимаю, можно ли это сделать вообще, или сама постановка задачи такого контроля есть ересь.



Исправлено 1 раз(а). Последнее : boba, 22.11.18 13:48

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

Боба много написал, стареет. Не может кратко излагать, или длинно, но хотя бы понятно (градационно как-то )

Не стал объяснять, что такое проводка в бухгалтерии, думал,
многие знают, так же, как и аналитика.
Проехали.

Вкратце

1. Есть некие данные (счета)
2. На основании этих данных надо вычислить другие данные (аналитики)

Проблемы

1. Подчиненные данные могут быть не найдены
2. Подчиненных данных может оказаться больше одного

Вопрос: Что делать будем?
Ответ: А чего хотите-то?

Я серьезно! Пока не поставлена явная и однозначная цель модификации решение невозможно!

Вариантов решения собственно 2. На ком будет ответственность за разрешение этих проблем. На пользователях или на разработчике

1. Не нашли или связь неоднозначная - прерываем операцию с сообщением об ошибке. Пусть пользователи сами разбираются с настройками и данными

2. Предусмотреть в алгоритме поиска подчиненных данных:
2.1. Некую иерархию. Приоритеты. Выбор в порядке приоритета. О чем и говорил Игорь
2.2. Обязательно предусмотреть некое значение по умолчанию, если в п.2.1. так ничего и не будет найдено. Это позволит исключить пустые значения

Но в этом случае "виноватый" во всем будет разработчик.

Да, Владимир, так примерно и есть, как вы написали.
Писал эту штуку не я , не я и придумывал способ конвертации,
но мне приходится эту штуку разруливать.
Пока я написал так, в своих процедурах также , как у них, убрав пресловутое rownum=1
Пропускаю через все известные проводки месяца, скрещиваю процедуру саму с собой,
и смотрю, нет ли дублей ( хотя их может и не пара, а больше.
Если есть , на форме 2 кнопки- первая показать- строку таблицы конвертации, которая дает один ключ аналитики,, вторая кнопка - второй.
Бух должен убрать одну неверную строку из таблицы конвертации, или как-то ее поправить,
чтобы она не привязывалась к такому варианту проводки. Причем он не должен создать дырку в конвертации.
Точно также, экспресс конвертация ( вычисление аналитики, но без ее присвоения)
позволяет ловить и не присвоенную аналитику.
Опять таки бух должен создать строку конвертации, которая даст аналитику, причем таким образом, чтобы другая аналитика этого же счета не стала двоить.
Все это уже работает и заняло много времени, что для меня не типично.
Вопрос, нельзя ли прямо при вводе строк конвертации ловить такие ошибки, тут проводок еще нет.
Есть некая далекая аналогия сортировки.
Корзина с яблоками разных сортов ( цвета, запаха, мягкости, размера), случайно там же груши нескольких сортов итд.
Нужна сетка сортировки, которая не оставила бы в корзине ни одного яблока, и при сортировке не возникло бы сомнения , куда положить каждое яблоко или грушу.
Ну или математически, есть исходное множество,
нужно рассортировать его в другое, не оставив ни в одном пустот, и не положив
в разные ячейки нового множества членов двойни.
Отсортировать, как говорит Игорь, тут не получается.
Другими словами сейчас ответственность частично на бухе,
частично на разработчике.
Бух вводит и правит таблицу конвертации,разработчик дает способ найти там липу
Но как вы написали-
1. Не нашли или связь неоднозначная - прерываем операцию с сообщением об ошибке. Пусть пользователи сами разбираются с настройками и данными
Так нельзя. В месяц полторы сотни тысяч проводок и больше,
Аналитик для некоторых счетов до 20-25 штук.
Сама конвертация занимает часы.
Каждый раз падать, может ради пары проводок нельзя,
провалишь отчетность на верх- секир башка.
Мой механизм экспресс конвертации позволяет минут максимум за 5 выявить все дубли конкретного двузначного счета и столько же времени на анализ пустоты.
Вопрос, нельзя ли поймать это на ранних рубежах обороны.



Исправлено 3 раз(а). Последнее : boba, 26.11.18 14:33

Мне кажется, не то что бы нельзя. Но нерационально. Дело в том, например, что проблема пропуска аналитики проявляется не только в момент редактирования настроечной таблицы, но и в момент редактирования таблицы с аналитикой. То-есть, проверку придётся делать и там, и там.

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

Думаю, Володя Максимов дал исчерпывающий ответ. Я не вижу других вариантов.

Вот это в яблочко.
Но такая проверка займет черт знает сколько времени,
в валид поместить нельзя, даже в кнопке сохранить-вряд ли

Гм... Перевожу

Есть некая таблица настроек

Вопрос: существуют ли в этой таблице "пересекающиеся" настройки?


Однозначного ответа нет. Ответ очень сильно зависит от алгоритма поиска

Например, есть две настройки. Одна с шаблоном 1234, другая с шаблоном 12345. И есть счет 123456. Оба шаблона подходят. Являются ли эти настройки пересекающимися?

Ответ на этот вопрос напрямую зависит от алгоритма поиска?

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

Если приоритета нет, то настройки пересекающиеся. Но опять же вопрос, а какая "лишняя"?

-----------------------------

Т.е. возвращаемся к тому, с чего начали. Надо менять алгоритм поиска вводя некие дополнительные сущности, которые позволят сделать выбор в случае неоднозначности идентификации по существующему алгоритму

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

-----------------------------

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

Нет никакого приоритета.
Аналитика по бух правилам это совершенно осмысленная вещь,
свойство денег, как их потратили или заработали.
Программист тут ничего сделать вместо буха не может,
это их кухня. Мы рулим ключами, они словами-
списали весело , или попросили.
На умников или чудаков потратили, с душой или жалко было.
С максимумом ключа или минимумом это никак не связать.
Думали про такой вариант, конечно.
Тут каждый новый месяц подкидывает новые варианты, которых не
было до этого, а уж конец квартала, года-вообще абзац.
Сейчас переход на новый НДс дает еще кучу новенького.
Покупали детали по 18%, а снимут с продукта 20%,
куда положить убыток. Начали выпускать партию по 18%,
а закончили под 20%.



Исправлено 1 раз(а). Последнее : boba, 27.11.18 08:24

boba
Нет никакого приоритета.

Что мешает его ввести?

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

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

Игорь,
напоминаю.
У программиста слова нет в лексиконе нет.
Пользователю нужно, и все.
Если он закон Ньютона будет требовать нарушить,
придется послушать. Увы , я не начальник.
На деле ситуация между тем, что вы описали и грубой
сортировкой. Тут деваться некуда, это корпоративная отчетность.

boba
У программиста слова нет в лексиконе нет.

Зато у программиста разработчика есть такое ДА, которое будет похуже любого НЕТ. Но донести это до заказчика бывает непросто.

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

Igor Korolyov
даже семь красных линий перпендикулярных друг другу можно запилить

Игорь, ну это вообще элементарно делается. Строятся семь перпендикулярных линий в семимерном пространстве, на экран, естественно, выдается проекция, собственно, как и в любом 3D. Все.

Тз к этому нет.
Документации к текущей реализации нет.
Даже элементарного описания таблиц нет.
Заказчик не в состоянии точно описать все это,
кроме того, чтобы нужно, чтобы верно.
Авторы программы канули в лету, фактически
она навязана сверху за очень крутые бабки.
Пока авторы были тут, все мои попытки туда влезь
пресекались как ими, так и пассивно заказчиком
и кучей других людей.
В таком положении сделано по максимуму,
это ведь только мелкая работа из сотни других.
Работает верно сейчас я бы сказал процентов на 98%,
а было процентов 80% максимум.
100% может и можно, но самому нужно быть бухом.

Дело было вечером Чисто формальный анализ

Постановка задачи

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

Контролируемые данные

1. Счет ГК - дебет
2. Счет ГК - кредит
3. Контрагенты
4. Статьи затрат

Очевидно, что имеющими пересечение можно считать только те записи, которые дадут пересечение по всем наборам контролируемых данных. Причем дебет и кредит в данном случае можно рассматривать независимо друг от друга. Т.е. надо просто последовательно сделать проверки на пересечение по каждому набору. Если все имеют пересечение, то это и есть, то, что ищем.

Если по какому-то набору критерии не указаны, то, очевидно, этот набор пересекается с любым другим набором.

Способ указания данных для контроля

- Любое значение рассматривается как первые символы искомого значения. Если указано XX, то ищем like 'XX%'
- Может быть указан список через запятую
- Может быть указано не искомое значение, а значение, исключаемое из поиска. Исключения.


Вопрос: Возможно ли найти "пересечение" только по таблице конвертации не анализируя собственно данные?
Ответ: Можно


Как?

Предположим, есть настройка конвертации "1234". Очевидно, что

1. "пересечение" этой настройки возможно со значениями, которые начинаются с этого же значения. Т.е. тех, которые длиннее. Ну, например, "12345"

2. Но, с другой стороны, само это значение будет подмножеством значений, которые короче. Это уже фиксированный набор: "1", "12", "123", "1234"

3. Если указаны исключения, то из рассмотрения следует исключить значения, которые начинаются с указанного исключения. Например, если указано исключение -123, то, очевидно, искать 1234, 12345, 123456 и т.п. уже смысла нет. Они попадют в исключение

Т.е. ищем записи таблицы конвертации, у которых шаблон поиска

- строго равно одному из указанных значений: "1", "12", "123", "1234". Возможные исключения берутся из этой же искомой записи. Той, где ищем эти значения

ИЛИ

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


Замечание

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

Недостаток

- Может просто физически не быть тех данных, которые попадают в пересечение. Это же контроль настроек, а не проверка по реальным данным.
- При определенных настройках исключений, можем посчитать пересечением, хотя это и не так.

Т.е. в любом случае, потребуется "ручная" проверка найденного списка "пересечений" на предмет того, что это действительно пересечения.


PS: Если шаблон - это не первые символы, а набор символов в произвольном месте строки, то это все не подходит. Работать не будет. Тут только по факту сравнения с реальными данными. Ну, или тестовая табличка, содержащая все возможные значения. Но это существенно больше по времени поиска займет

-----------------------------------------

Можно пойти более простым, но менее надежным путем - сбор статистики

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

по любому надо начинать переписывать с "нуля". Это стандартная участь программ. Выбрать кто будет переписывать, (сторонние ребята, или местная команда из 1 чела). Это вопрос дира, и вопрос ЗП, ФОП-а, и начальника разработки, наскольно он способен возглавить разработку, и насколько он молод, чтобы дотащить разработку до рабочей версии, хотя-бы )

()
Аналитикой только и занимаюсь нынче. Набибулина не дает, расслабиться, но и собственно работой с конторой работать не дает. Это так будет в варианте "я сам сделаю", хз, работы много прибавили. Конечно, все это растащится со временем, решится, но пока чето заваливают, как в анеке.

Анек
На папин комп залез Вовочка, боролся с игрой (прогой 1С, Вовочка не знал, что это не игра), пока его налогами не завалили...



Исправлено 1 раз(а). Последнее : of63, 16.12.18 20:40