Кол-во просмотров с 19.02.24г. :: 248
Всем привет. Пока что вижу Елену. Больше пока никто не подошел. Будем потихонечку продолжать. А вот Наталья. Добрый день. Переходим к нашему программному коду. Мы вот здесь вот написали, что продолжение 14.02, то есть сегодня. Но я тему сегодня обозначил – база данных структуры статей DDS. Мы все-таки сегодня попробуем сделать два шага. Допилить вот этот вот программный код, который мы здесь корректируем в соответствии с новой структурой статей. И потом мы вот эту вот самую структуру статей, которую вот здесь мы создали, мы ее оформим в виде базы данных. Так, чтобы сразу же продумать вопросы о том, каким образом будут меняться, например, названия. То есть здесь есть тоже очень важные моменты, которые связаны, я уже говорил об этом, но еще раз просто повторю, это вот прям такая болевая такая точка. То есть вот представим себе, что мы в базе данных, учета фактически операций, храним название статей, к которым мы отнесли те или иные операции. И у нас в базе данных, если они хранятся в виде просто названий по-русски записанных. Где у нас тут? IT for FinFARBD. Если в базе данных мы видим названия вот в таком виде, доход, поставка, оплата за материал, оплата УК, и так далее. Ну, а допустим, мы выверим все вот эти вот названия, у нас там будет выпадающий список, и мы будем названия записывать вот в таком вот виде. Ну, как вот у нас в системе статей. Продажи товаров, оплата представительских расходов, оплата сырья и материалов. Ну, и вот как вот здесь мы Допустим, мы это все поменяем, приведем в соответствие. Но если вдруг потом, в какой-то момент времени, нам понадобится поменять какое-нибудь из вот этих названий, то получается, что по названию у нас пропадет стыковка с базой фактических операций. А нам все-таки нужно чтобы система была устойчива к таким простейшим, казалось бы, изменениям. И вот этот момент нужно будет продумать. Это также все уже давно понятно, как это все решается. То есть мы либо создаем систему синонима, то есть администратор системы должен, так скажем, в базу данных, структуры статей. Для каждой статьи должен формировать список синонимов, которые наследуются из прошлого, да? То есть у нас, если мы в прошлом называли там, например, оплату уставного капитала, оплата УК, мы, например, записывали статью, а потом решили ее поменять на оплата уставного капитала. Вот чтобы в базе данных все вот эти вот строчки которые записаны как оплата УК, чтобы это все не менять, оплата уставного капитала на новое название, так чтобы у нас бились ретро-данные, фактически данные прошлых периодов с новыми данными, когда мы вдруг поменяли название статьи. Нам понятно, что нужно для этих статей, для этой статьи необходимо ввести список синонимов, и по синонимам говорить, что если где-то мы встречаем синоним, то это именно вот эта статья. Это с одной стороны, либо для каждой статьи вводить систему кодировок, вот то, о чем мы вчера в том числе говорили, вот там, где Константин задавал вопрос про вот эти вот кодировки. Но я вообще говоря не приверженец вот этих вот кодировок. Почему? Потому что кодировка, когда вы вводите систему кодировки и всю, так скажем, кухню свою учетную строите через коды, то тут возникает, конечно же, одна достаточно такая серьезная проблема. которая состоит в следующем, что если вы через какой-то код задали какую-то статью, то это значит вы этот код, вот такой вот числовой код, наделили некоторым жизненным свойством, что за этим кодом, если 2.1.5 записано, за ним всегда стоят только какие-то оплаты погруза-разгрузочных работ, только такой тип действий, такой тип операций. И получается, что в жизни, если вы сталкиваетесь с каким-то действием, которое похоже на погрузоразгрузочные работы, но, например, как-то по-другому будет называться. Допустим, вы получаете от поставщика товарную накладную, в которых будет написана такая запись, да, там упаковка, упаковка, там, не знаю, упаковка каких-нибудь там вещей на месте и погрузка в автомобиль, в авто. Что-нибудь такое. Ну, какая-нибудь странная такая запись, которую необходимо отнести к статье за трат. И эта статья затрат в общей большой как бы вот этой массе, вот в этой в простыне, вы видите только коды. И вам, если вы все делаете через систему кодирования, то если вы в товарной накладной поставщика встречаете какую-то вот такую запись, то вам там, например, если это бухгалтер ведет, вы на бухгалтера не дай бог повесите такую задачу, чтобы она правильно вот эти коды навешивала. Так это надо тогда глазами просмотреть, какие у вас здесь есть возможности. И если вы не смогли понять, что по сути вот эта вот упаковка вещей на месте и погрузка в авто – это то же самое, что погрузоразгрузочные работы, допустим, да, и вы, например, не нашли в системе статей, ну для себя просто не поняли, к чему это отнести, то вы начинаете создавать новый код, И тогда у вас начинает создаваться достаточно большое количество различных кодов, на которые вы что-то навешиваете, какие-то похожие статьи и так далее. Лично мне это не очень нравится. Это система работы с какими-то числовыми позициями и так далее. И получается так, что если у вас возникает какая-то ошибка, какое-то такое двусмысленное понимание той или иной услуги, того или иного действия, той или иной затраты, которая где-то очень близка к чему-то, но вы просто по названию, по этим кодам не можете как бы найти, сразу же как бы их связать, то фактически на предприятиях, и я это встречал, начинается там различные отделы начинают генерировать достаточно большое количество вот этих вот кодовых сочетаний. Каждое кодовое сочетание это какая-то новая статья затрат и вот эти вот я видел эти справочники вот таких вот создаются целые огромные такие справочники статей затрат, статей там всяких доходов и расходов. Огромное количество каких-то вот этих вот кодов у них там прописывается. И это вот как раз-таки результат вот такого подхода. Мне больше нравится, когда мы вводим какой-то код и создаем какие-то синонимы. То есть мы накидываем, В принципе, плюс-минус — это почти то же самое. Все равно нужно как бы определять, к чему что отнести. Ну, в общем, тут надо выбирать. Короче говоря, мне больше нравится, когда мы создаем синонимы. То есть, когда мы про коды забываем, по большей части, коды мы как-то там установили, этим занимается администратор системы. А люди, ну, более-менее там пытаются смотреть на сутевые какие-то вещи, и если просто по смыслу там где-то как-то это синонимично подходит, какие-то вот эти вот названия, то просто закидывать в виде вот этих вот синонимов. Тоже я это сейчас как раз-таки покажу. Так, у нас как там? Раз, два, три, четыре, пять. Четыре человека у нас, да, сейчас уже Наталья, Елена, Константин, Павел. на месте. Пока еще не все собрались. И как эту систему синонимов создать в рамках структуры статьи, я это сейчас покажу. А действовать она будет следующим образом. То есть у нас есть последние названия этой статьи. И если у этой статьи были до этого какие-то синонимы в прошлом, например, мы как-то это называли, то мы, по крайней мере, в базе данных это не меняем, а просто у нас программный код, он считывает, если он видит синоним, то он, соответственно, этот синоним будет относить, соответственно, к той статье, в которой этот синоним прописан, где он там сидит. Потом я это покажу и дальше поедем. Ну а сейчас наша задача состоит в следующем. Наша задача все-таки состоит в том, чтобы мы вот этот вот программный код выдачи числовых значений доработали. Чтобы вот этот вот отчет кэш-флор, отчет о движении денежных средств, чтобы вся вот эта вот числовая часть, она должна у нас сохраниться. Она у нас здесь корректно сейчас отображается. И после того, как мы перейдем на новую систему статей, нам нужно, чтобы у нас оно и дальше корректно отображалось, корректно отображались вот эти числовые значения, суммовые. Как только мы в этом убедимся, Мы перейдем вот к этому заявленному сегодня, к заявленной теме. База данных структуры статей ДДС. Я покажу, как ее сделать. И, соответственно, мы уйдем с вами от вот этого блока, где мы вручную фактически прописываем всю структуру. Мы сделаем так, что у нас появится администратор нашей системы, он сможет просто-напросто через кнопочки, через интерфейс менять структуру статей, добавлять статьи и так далее. С введением сегодня я закончил. Еще пока что у нас... Леонид и Давид уже не подтянулись. Ладно, едем дальше. Значит, расчеты для подразделок. Я шел вот до DS-блока. Значит, мы создаем систему из трех уровней статей, и у нас получается три цикла вложенных. Значит, я еще раз пробегу. Когда мы заходим в первый блок, то далее мы в рамках первого блока, мы создаем кэш-флойст первого блока, массив статей первого блока задаем. И здесь мы пишем, что если в структуре статьи отсутствует статья второго уровня, то есть если внутри этого блока отсутствуют статьи, то мы переходим… Если отсутствуют статьи, то тогда мы, в принципе, готовы рассмотреть вопрос о том, что у нас по этому блоку только верхнеуровневая статья. И давайте посмотрим, что у нас здесь записано. Мы используем переменную статья, $статья, и, соответственно, ей присваиваем значение.