Хм. Наверное потому, что с момента, как я эту автоматику сделал, в голове так и остался sysvinit. Плюс еще я не сисадмин, по сути, а так, дилетант, знающий много что горизонтально, но не в деталях, и в systemd особенно не вникал.
Вообще, Ваш план выглядит заманчиво и технологично, но это целая новая статья.
К моменту, когда меня пригласили, заказчиком куплены были уже именно такие.
В принципе, сама автоматика не привязана к архитектуре, статья подойдет и для Orange. Экономически, естественно, лучше ваши варианты.
На днях хочу себе заказать апельсинку для опытов, но пока в стадии выбора модели.
Мне (для другой задачи) нужна SATA на PCI-E, а на ту модель Orange, где это есть, люди жалуются.
Да, Вы правы. Rdesktop откровенно стар, просто я с ним давно, и знаю его грабли.
Если надо заменить на другой — в принципе, меняем раздел 2.9 на другой софт:
apt-get install freerdp-x11
и содержимое скрипта runrdp будет чуть другое — вызываем не rdesktop а xfreerdp, с другими параметрами.
Я больше хотел донести до аудитории автоматику переподключения.
Касательно сетевого развертывания — тоже хороший вопрос. Я когда-то пытался идти именно по такому пути (плюс даже сетевой загрузки ядра), еще лет 10 тому назад (не с rpi, разумеется). Это требует дополнительной инфраструктуры — надо донастроить DHCP-сервер, развернуть сетевой корень, и т.п. Все это периодически сбоит и сношает мозг.
А еще клиенты-неттопы докупаются по несколько штук в разное время, у них разные видеодрова (особенно досаждали патченные интеловские, которые вытесняли ванильные), и общий корень им заходит плохо.
Поэтому я пришел к такой схеме, как наиболее экономически целесообразной, и дешевой как для меня, так и для заказчиков.
А еще представляете, насколько бы выросла статья, если сюда воткнуть нюансы сетевой загрузки? Я чего-то и так переборщил.
Что касается обновлять и сопровождать (воровато озираюсь), то, я сейчас, конечно, посягаю на догму, но зачем обновлять и что там сопровождать?
Из порядка 50 станций (опять таки не на RPi, я про прошлые годы), которые ставил лично я, либо склонированные сисадминами у клиентов из моих образов, ни к одной не потребовалось возвращаться. Из них уже 70% выведены из эксплуатации по причине отпадания необходимости, а на некоторых из тех, что выжили, до сих пор Debian etch и lenny.
Если надо менять логин и узел подключения часто, наверное, разумным компромиссом было бы в скрипте runrdp подставлять эти параметры, выдергивая их dhclient-ом по DHCP.
Нет, то что я написал, относится к случаю у.е., потому что при нем счет-фактура должна быть выписан в рублях. Просто 90% договоров, которые я видел, под 1 у.е. подразумевали «1 ед. какой-то валюты по курсу ЦБ на дату оплаты». Поэтому я нечаянно опечатался, использовав слово «валюта» в середине сообщения, если Вы про это.
Именно с у.е. счетами-фактурами все сложно. С одной стороны, из норм бух. и налогового учета следует, что что сначала надо сосчитать сумму у.е. всей сделки и затем определить ее общее рублевое покрытие, с учетом курса у.е. и возможных предоплат.
С другой стороны действует упомянутые Вами и выше по треду, и другие смежные нормы, предписывающие считать сумму документа и НДС в нем построчно индуктивно, да еще и с переводом в рубли.
С третьей стороны, сумма итого на документе должна сходиться с суммой определенной двумя абзацами выше, иначе взаиморасчеты не пойдут с напечатанной первичкой.
Тогда получается, что определив рублевое покрытие у.е. реализации мы должны все строки сконвертировать в рубли, но так, чтобы итог сошелся с вычисленным рублевым покрытием. А для этого не умножать каждую строку на курс, чтобы получить итого, а наоборот — распределить общую рублевую сумму пропорционально у.е в строках. Ну или пересчитать построчно по вычисленному курсу, а разницу отнести на какую-то одну строку.
А потом исходя из этого в каждой строке рассчитать НДС (и собрать в общий НДС), вычесть из суммы всего и поделить на количество, чтобы определить цену.
И никак не наоборот, иначе не сойдетесь с общей рублевой суммой, определенной по правилам бухучета.
По итогу, мало того, что расчет не совсем соответствует порядку, да еще и в каждой строке форме условно выраженные соотношения:
соблюдаться в этом случае не будут. Т.к. цена в руб., получается, рассчитана от обратного — от суммы с НДС, за минусом НДС, поделенная на количество. Даже для одной строки у вас обратный расчет не пойдет.
А налоговая, на моей памяти, буквально недавно открывала кампанию по преследованию счетов-фактур, в которых такие соотношения и порядок не соблюдались (правда в основном по другой причине — из за фиксации цены с НДС), и снятию их с вычета, и в этом вопросе кто-то даже доходил высоко по арбитражу, защищая свой поруганный вычет.
Особенно весело пытаться применять этот пункт к счетам-фактурам/УПД, выставленным по сделкам в у.е. (сами документы печатаются в рублях)
Там мало того, что общая рублевая сумма документа (не НДС, а вообще) исчисляется «снаружи» с учетом курса на день и курса предоплаты (требования нормативки по бухучету), и бывает противоречит построчному расчету, так еще и в каждой строке цена изначально установлена спецификацией в валюте, а при пересчете в рубли совершенно разваливается соотношение Количество*Цена = Сумма (с учетом округлений и расчета НДС).
С одной стороны, 1С платформа и основанные на ней подходы к написанию типовых конфигураций (и вообще конфигураций) становятся настолько громоздкими, что прекращают помещаться в разумные нормы, и начинают требовать «переосмысления». Я не смогу качественно поддержать дискуссию по этому вопросу, т.к. не считаю себя хорошим программистом, но я согласен с доводом, и мне много что не нравится в платформе и типовых конфах. Например, как сделана асинхронность, как построены типовые подсистемы в БСП, и как подключаются к объектам, области видимости общего кода, связность внешних обработок с основной конфигурацией на УФ, несовершенство расширений, и др.
С другой стороны, предметная область (законодательство прежде всего) неконтролируемо разрастается и впадает в маразм настолько, что в одном продукте откровенно перестает не просто логично укладываться, но и вообще помещаться (с технико-архитектурной стороны вопроса), но при этом должно (с точки зрения хоть какой-то юзабельности).
Поясню на примере той же ЗУП. В ЗУП есть, фактически, следующие участки:
— кадровый учет, штатка*
— воинский учет*
— работа с ПДН (включая как соответствие законодательству о ПДН, так и адресную информацию по классификаторам)
— расчет зарплаты и учет взаиморасчетов по зарплате *
— элементы бухгалтерского учета всего этого, для выгрузки в БП
— учет по страховым взносам
— налоговый учет по НДФЛ *
— налоговая отчетность по всему этому и ее выгрузка *
— электронная интеграция с внешними системами (банки, ФСС в части эл. больничных и др)
И вот почти каждый из этих участков (а в особенности те, которые отмечены *) регулируется толстенными разделами кодексов (ТК, НК, ПБУ), кучей нормативной актов, регламентов и ФЗ россыпью, требует от пользователя отдельной глубокой компетенции (прихожу к выводу, что для НУ по НДФЛ теперь для >50 сотрудников вообще надо учить отдельного бухгалтера, чтобы сдать хоть что-то правдоподобное, т.к. в большинство людей это не помещается вкупе с другими требуемыми компетенциями), но главное — совершенно безумно по-своему.
Отцепить из этого что-то одно и выделить в unix-way в отдельный продукт — не представляется возможным. Все очень неочевидно переплетено между собой, и упирается в одни и те же оперативные данные. А дублировать 80% оперативных данных между разными продуктами бессмысленно: либо выгрузки будут косячить, либо люди, либо рук не хватит перебивать и актуализировать.
А если какую-то функциональность выкинуть вообще, продукт станет совершенно бесполезен, перестанет, так сказать, быть «минимально функциональным», т.к. полный комплект отчетности через него не сдашь.
И каждый год приносит какие-то фундаментальнейшие новшества. Так, если брать бухгалтерию и продажи, то: детальная отчетность по НДС, онлайн-кассы почти для всех и всего, маркировка, все более обязательный ЭДО, и др. А еще уважающая себя бухгалтерия должна уметь вести налоговый учет по ОСНО (в вариантах для ООО и ИП), УСН, сдавать отчеты по всему этому, плюс еще в статистику.
И во все это надо заложить кучу степеней свободы, т.к. исполнительные органы трактуют в каждом регионе нормы по-своему, а нормативные акты имеют склонность друг другу прямо противоречить по одним и тем же вопросам так, что провести учет с минимумом рисков невозможно — вас обязательно найдут за что вздрючить. Поэтому пользователи на местах предъявляют совершенно различные требования к продукту.
И это все относится почти к каждому предприятию, а я еще не беру сложные случаи типа лизинга, факторинга, ЕГАИС/ЛЕГАИС, и т.п.
И в таких условиях — переосмысливай, не переосмысливай подходы, все равно конфигурация будет представлять из себя кучу и сильно и слабосвязанных архитектурно различных модулей (что общего между лизингом и интеграцей с онлайн-кассами?). И будет 15 временных таблиц в запросе, потому что сборка какой-нибудь отчетности по страховым взносам требует залезть почти во все модули учета, включая кадровый, зарплатный, добавить ПДН-ы, развернуть это все по периодам, перегруппировать, и т.п.
Кстати, обратите внимание — вменяемых конкурентов прикладным решениям 1С мало, ИМХО, потому что такой вот огромный, но «минимально требуемый» объем функциональности, вкупе с регулярными обновлениями, в коробке, и за выносимые деньги, разыскать невозможно. И войти в этот рынок теперь тоже, т.к. объем инвестиций в готовый минимальный продукт просто какой-то нереальный, что конечно же скажется на конечной стоимости, либо отсечет даже попытки начать.
Ну, в контексте моего исходного сообщения — «с волками жить — по волчьи выть». Мимикрировались.
А если серьезно — наверное Вы правы, но я сам не могу оценить по сути. Из всех типовых конф меньше всего всегда вмешивался в код именно ЗуП/ЗиК и их модули в УПП/КА. Во-первых, вообще не люблю трогать типовой код. Во-вторых, реже всего требовалось. В-третьих — страшно.
С отладкой сложно во всем 3-м поколении конф. И текст запроса по кускам склеивается на коде, и временные таблицы гоняются через стек в 20 вызовов. Я даже себе расширение сделал специальное, в котором модуль, экспортная функция которого мне из МВТ извлекает и возвращает содержимое временной таблицы — для анализа в калькуляторе отладчика.
Но сам по себе, допустим, запрос из 15 временных таблиц для зарплатно-кадрового учета — вполне норма (с точки зрения написания своих отчетов и доработок), т.к. там куча мест (регистров и справочников) где лежат НДФЛ, страховые взносы, сама зарплата, кадровый учет (с его постоянными и временными переводами), и все это очень сложно организовано, и сложно соединять Бывает, сам напишешь что-то, ОТКОММЕНТИРУЕШЬ как можешь, а через год усомняешься в том, ты ли это писал, и был ли при этом трезв.
Восприятие кода — понятие субъективное. Я, возможно, не понимаю света, которым лучится современная кодовая база БСП и типовых конф, просто потому что начинал еще с 7.7 (где не то, что асинхронностью — даже нормальными запросами еще не пахло), и занимаюсь не только 1С. Кроме того, хотя я и могу глубоко писать код, я больше методолог и специалист по организации учета, чем программист.
Но если бы Вы могли выразить мне мнение по паре вопросов общего характера, как раз по БСП, которые не дают мне спать, то я был бы очень признателен. Не знаю только, уместно ли задать на форуме, или лучше в личку.
ИМХО относительно ЗУП рептилойдов надо искать на Охотном ряду, Ильинке и в Рахманиновском переулке, а не в 1С.
Законодательная база такова, что как только расчет зарплаты и кадровый учет выходят из простого случая «Оклад + премия каждый месяц, 1 раз в год отпуск, а свои больничные пусть сотрудник засунет себе в...», хочется застрелиться под столом еще даже не открыв программу, потому что совершенно непонятно как обсчитать все это даже на бумаге, и не подставиться хоть каким-нибудь местом.
Команда 1С в этом плане выкручивается как может, и ухитряется предъявить не только достойный работающий продукт (не без косяков, ес-но), но еще и как-то предугадать развитие крайне волатильной и безумной законодательной базы и заложить некие степени свободы, чтобы через полгода конфигурация не перестала соответствовать вообще всему (ну это если мы отбросим теорию заговора, что собственники 1С лоббируют развитие бизнес-законодательства в интересах бесконечного развития семейства продуктов 1С).
ИМХО, сама по себе это отличная вещь (как и БПО и БИП). Незаменимая при разработке собственных конфигураций, с кучей нужных модулей и т.п. Даже сам факт наличия БСП в конфе переводит заштатную нетленку в разряд почти-что-1с-совместимо.
Вопрос, как она написана внутри и куда, вместе с кодом типовых конф, развивается.
Очень избыточна, очень лапшеобразна. Комментариев, хотя бы намекающих, почему на достаточно простое действие надо 500 строк кода и стек глубиной в 20 вызовов (для разборки в котором нужен коньяк), крайне мало (нет вообще). Документация не очень хорошая, и материалов в открытом доступе тоже особо нет. А асинхронность вызовов превратило реверс-инжиниринг существующей кодобазы типовых конф (чтобы понять КАК это работает), и отладку, вообще в лютый ад.
Майнстримовые вещи (подходящие и одинаковые для большинства клиентов) в типовых (не отраслевых) конфигурациях сделаны реально хорошо.
Когда же начинается специфика (редко встречающиеся участки или сочетания учета, или особые пожелания клиента), все, конечно, становится немного сложнее.
В принципе, и простой и сложный клиент платят за продукт и за подписку на 1С одинаково, с коммерческой стороны — незачем перенапрягаться. Ну и, конечно, всем не угодить. Ну и армию подрядчиков тоже надо подкармливать. Ничего личного, чисто бизнес.
Я вот 1с-ом занимаюсь уже лет 15, эта технология, в целом, меня исключительно неплохо кормит, и мне нравится.
Заказчики полагают меня неплохим спецом, хотя я сам не склонен переоценивать свои навыки. Но когда разбираюсь в коде типовых конфигураций и БСП, у меня всегда возникает столько вопросов… столько вопросов… к разработчикам прикладных решений… и людям, которые их контролируют… А в этой статье почти все ответы даны. Вот прям по пунктам моих вопросов.
Они (ответы), конечно… более цензурны, чем я сам себе отвечал, но в целом процесс соответствует ожидаемому. Хотя бы теперь понимаю, почему так. Мне теперь будет чуть проще жить и относиться к этому.
Спасибо, было интересно. Поздравляю, что «вырвались из Омска», и удачи на новом поприще.
Хотя я это и читал уже ранее, просто, похоже с тех времен стал старше, и релевантность материала опыту резко повысилась. Короче, тогда было менее весело.
Вас извиняет только то, что от слез, похоже, прошел конъюнктивит.
Прошу прощения за невежество, а что именно имеется ввиду под сквозными моделями? Упручет через все организации?
Что касается БУ с НУ, то тут еще есть несколько НУ — НУ по налогу на прибыль, НУ по НДС (особенно в ряде случаев, когда его надо восстанавливать в разрезе материалов при льготной реализации продукции), НУ по НДФЛ, НУ по страховым взносам, НУ по налогу на имущество (целый контур наслоений льгот и разных ставок, с поправкой на специфику по регионам). Если УСН 15%, то НУ по УСН, или даже НУ у ИП на общей системе налогообложения (свят-свят).
И для каждого надо отдельную голову иметь.
Хочется куда-нибудь забиться под кровать и застрелиться от обилия нормативной базы.
Скорее речь идет о выработке разумных компромиссов между возможностями и степенями свободы используемого инструмента и пожеланиями и платежеспособностью заказчика.
С другой стороны, ERP-подобные системы пишут опытные люди, и если они предложили в системе какой-то готовый процесс, то его следует хотя бы рассмотреть и примерить на себя. Возможно не зря так сделали.
какое отношение имеет бухгалтерия к номенклатурам, которые в норме создаются отделом снабжения (для чужих) и исследований и разработок (для своих)? Тем более что момент оформления прихода А) заказ на закупку был создан еще 2 недели назад и Б) приход уже был в цифровом виде оформлен сотрудниками склада?
То, что Вы написали в цитате, когда оно в единой базе, это как раз продукт хорошей автоматизации и грамотного выстраивания процессов, и вообще 1/3 внедренной ERP.
По моему опыту, пока все живут в зоопарке разных клочковых баз (как я писал выше), такой проблемы нет.
Как только сажаешь бухгалтерию и профильные службы в одну лодку (что естественным образом должно произойти при внедрении ERP-подобной системы — прямо, или косвенно, через выгрузку) — начинается: «Да как это так, что номенклатуру кто-то заводит? Да она должна прописываться строго как в приходной накладной!».
Часто, при этом, бухгалтерия (как структура, достаточно близкая к руководству, наиболее авторитетная по возрастному признаку, да еще и обладающая опытом использования «самых современных» программ автоматизации) таки продавливает свою позицию (вбивать, как в накладной), чем погружает оперативку в жесточайший хаос.
Каждый проект, когда приходится ломать эту концепцию, примиряя их между собой (а по факту — ломая бухгалтерию в пользу внятного классификатора, удобного оперативщикам, и поручая его ввод последним), седеет очередной клочок волос.
Даже сложился отличный сигнальный критерий. Смотрю, как в бухгалтерской базе заведены хоз и канцтовары. Если карандаши, ручки, ластики вбиты по артикулам, а бумажные стикеры по размерам — то обычно все, это полярный лис. Это будет больно. А если просто «карандаш», «ручка», «стикеры», или даже «канцтовары на сумму» — то договоримся и по метизам.
По остальной части Вашего сообщения у меня нет комментариев, я хотел только поделиться вышеизложенным.
Да, теперь увидел.
Просто на фоне слез умиления застлавших мне глаза, ну и учитывая, что я сам никогда не подвергал сомнению необходимость внедрять ERP-системы (при разумном подходе и известной целесообразности), не акцентировал на этом свое внимание.
Самому случалось писать статьи, в которых часть, посвященную плАчу Ярославны я излагал, а на то, как надо делать правильно — времени не оставалось.
Видимо, руководство предприятия и автор статьи не знают бизнес-процессы на своем предприятии
Ну, автор, как я понял, не имеет ввиду конкретное предприятие, он просто широкопрофильный консультант, выложивший статью в промо-целях для абстрактного случая, хотя и основанного на чьем-то реальном опыте.
А вот то, что руководство предприятий часто совершенно не понимает своих бизнес-процессов (и не хочет даже вникать), не может контролировать подрядчика по внедрению ERP, а подрядчик не пытается вправить предприятию мозг на уровне процессов, схем и решений, а пытается продать красиво завернутое «ничего», что-то сделать наобум и побыстрее свалить, прикрываясь бумажками, опрометчиво подписанными заказчиком, а сотрудники не подчиняются и саботируют (это уже реже, и не так важно, и скорее следствие), что по итогу приводит к плачевным итогам, — по моим наблюдениям, чуть ли не норма. Какая-то чертова системная ситуация просто. Позитивных примеров на порядок меньше.
Правда это лишь мои наблюдения, ограниченные выборкой из нескольких десятков предприятий в небольшом регионе ЦФО и немного в соседних. Поэтому статья показалась мне релевантной проблемам, которые я разгребаю, потом, каждый день. А может это просто место проклятое…
Не всегда компания принадлежит автору (я вообще имею ввиду, а не конкретно этого), не всегда автор принимает решение. Иногда какому-нибудь компетентному автору, пусть находящемуся, скажем, на высокой должности и хорошем окладе (но с которым смирились, как с условно-постоянными расходами) приходится грустно смотреть, как продажники от компании с высокой почасовой ставкой (а за углом, как в анекдоте, все еще на 600 баксов дороже, да), и хорошими часами и костюмами, обработали топ-менеджмент, и решение было принято, в обход рекомендаций автора, людьми, которые не очень понимают суть автоматизации вообще, и не читали даже подобного текста, в частности.
К автору-то, может быть и так очередь, он к стулу не прирос и, если что уволится, чтобы за эту богадельню ответственность потом не нести, но кейс пополнится такими вот ситуациями.
И хотя стиль изложения конкретно этого текста, конечно, забавен, направлен на PR, а для специалиста пестрит прописными истинами, какой-либо неправды тут не написано (ИМХО), и суть достаточно понятна для ЛПР. Может быть одному из них хоть такой «научпоп» нагуглится на глаза во время разборов протоколов совещаний.
Вообще, Ваш план выглядит заманчиво и технологично, но это целая новая статья.
В принципе, сама автоматика не привязана к архитектуре, статья подойдет и для Orange. Экономически, естественно, лучше ваши варианты.
На днях хочу себе заказать апельсинку для опытов, но пока в стадии выбора модели.
Мне (для другой задачи) нужна SATA на PCI-E, а на ту модель Orange, где это есть, люди жалуются.
Если надо заменить на другой — в принципе, меняем раздел 2.9 на другой софт:
и содержимое скрипта runrdp будет чуть другое — вызываем не rdesktop а xfreerdp, с другими параметрами.
Я больше хотел донести до аудитории автоматику переподключения.
Касательно сетевого развертывания — тоже хороший вопрос. Я когда-то пытался идти именно по такому пути (плюс даже сетевой загрузки ядра), еще лет 10 тому назад (не с rpi, разумеется). Это требует дополнительной инфраструктуры — надо донастроить DHCP-сервер, развернуть сетевой корень, и т.п. Все это периодически сбоит и сношает мозг.
А еще клиенты-неттопы докупаются по несколько штук в разное время, у них разные видеодрова (особенно досаждали патченные интеловские, которые вытесняли ванильные), и общий корень им заходит плохо.
Поэтому я пришел к такой схеме, как наиболее экономически целесообразной, и дешевой как для меня, так и для заказчиков.
А еще представляете, насколько бы выросла статья, если сюда воткнуть нюансы сетевой загрузки? Я чего-то и так переборщил.
Что касается обновлять и сопровождать (воровато озираюсь), то, я сейчас, конечно, посягаю на догму, но зачем обновлять и что там сопровождать?
Из порядка 50 станций (опять таки не на RPi, я про прошлые годы), которые ставил лично я, либо склонированные сисадминами у клиентов из моих образов, ни к одной не потребовалось возвращаться. Из них уже 70% выведены из эксплуатации по причине отпадания необходимости, а на некоторых из тех, что выжили, до сих пор Debian etch и lenny.
Если надо менять логин и узел подключения часто, наверное, разумным компромиссом было бы в скрипте runrdp подставлять эти параметры, выдергивая их dhclient-ом по DHCP.
Именно с у.е. счетами-фактурами все сложно. С одной стороны, из норм бух. и налогового учета следует, что что сначала надо сосчитать сумму у.е. всей сделки и затем определить ее общее рублевое покрытие, с учетом курса у.е. и возможных предоплат.
С другой стороны действует упомянутые Вами и выше по треду, и другие смежные нормы, предписывающие считать сумму документа и НДС в нем построчно индуктивно, да еще и с переводом в рубли.
С третьей стороны, сумма итого на документе должна сходиться с суммой определенной двумя абзацами выше, иначе взаиморасчеты не пойдут с напечатанной первичкой.
Тогда получается, что определив рублевое покрытие у.е. реализации мы должны все строки сконвертировать в рубли, но так, чтобы итог сошелся с вычисленным рублевым покрытием. А для этого не умножать каждую строку на курс, чтобы получить итого, а наоборот — распределить общую рублевую сумму пропорционально у.е в строках. Ну или пересчитать построчно по вычисленному курсу, а разницу отнести на какую-то одну строку.
А потом исходя из этого в каждой строке рассчитать НДС (и собрать в общий НДС), вычесть из суммы всего и поделить на количество, чтобы определить цену.
И никак не наоборот, иначе не сойдетесь с общей рублевой суммой, определенной по правилам бухучета.
По итогу, мало того, что расчет не совсем соответствует порядку, да еще и в каждой строке форме условно выраженные соотношения:
соблюдаться в этом случае не будут. Т.к. цена в руб., получается, рассчитана от обратного — от суммы с НДС, за минусом НДС, поделенная на количество. Даже для одной строки у вас обратный расчет не пойдет.
А налоговая, на моей памяти, буквально недавно открывала кампанию по преследованию счетов-фактур, в которых такие соотношения и порядок не соблюдались (правда в основном по другой причине — из за фиксации цены с НДС), и снятию их с вычета, и в этом вопросе кто-то даже доходил высоко по арбитражу, защищая свой поруганный вычет.
Там мало того, что общая рублевая сумма документа (не НДС, а вообще) исчисляется «снаружи» с учетом курса на день и курса предоплаты (требования нормативки по бухучету), и бывает противоречит построчному расчету, так еще и в каждой строке цена изначально установлена спецификацией в валюте, а при пересчете в рубли совершенно разваливается соотношение Количество*Цена = Сумма (с учетом округлений и расчета НДС).
С одной стороны, 1С платформа и основанные на ней подходы к написанию типовых конфигураций (и вообще конфигураций) становятся настолько громоздкими, что прекращают помещаться в разумные нормы, и начинают требовать «переосмысления». Я не смогу качественно поддержать дискуссию по этому вопросу, т.к. не считаю себя хорошим программистом, но я согласен с доводом, и мне много что не нравится в платформе и типовых конфах. Например, как сделана асинхронность, как построены типовые подсистемы в БСП, и как подключаются к объектам, области видимости общего кода, связность внешних обработок с основной конфигурацией на УФ, несовершенство расширений, и др.
С другой стороны, предметная область (законодательство прежде всего) неконтролируемо разрастается и впадает в маразм настолько, что в одном продукте откровенно перестает не просто логично укладываться, но и вообще помещаться (с технико-архитектурной стороны вопроса), но при этом должно (с точки зрения хоть какой-то юзабельности).
Поясню на примере той же ЗУП. В ЗУП есть, фактически, следующие участки:
— кадровый учет, штатка*
— воинский учет*
— работа с ПДН (включая как соответствие законодательству о ПДН, так и адресную информацию по классификаторам)
— расчет зарплаты и учет взаиморасчетов по зарплате *
— элементы бухгалтерского учета всего этого, для выгрузки в БП
— учет по страховым взносам
— налоговый учет по НДФЛ *
— налоговая отчетность по всему этому и ее выгрузка *
— электронная интеграция с внешними системами (банки, ФСС в части эл. больничных и др)
И вот почти каждый из этих участков (а в особенности те, которые отмечены *) регулируется толстенными разделами кодексов (ТК, НК, ПБУ), кучей нормативной актов, регламентов и ФЗ россыпью, требует от пользователя отдельной глубокой компетенции (прихожу к выводу, что для НУ по НДФЛ теперь для >50 сотрудников вообще надо учить отдельного бухгалтера, чтобы сдать хоть что-то правдоподобное, т.к. в большинство людей это не помещается вкупе с другими требуемыми компетенциями), но главное — совершенно безумно по-своему.
Отцепить из этого что-то одно и выделить в unix-way в отдельный продукт — не представляется возможным. Все очень неочевидно переплетено между собой, и упирается в одни и те же оперативные данные. А дублировать 80% оперативных данных между разными продуктами бессмысленно: либо выгрузки будут косячить, либо люди, либо рук не хватит перебивать и актуализировать.
А если какую-то функциональность выкинуть вообще, продукт станет совершенно бесполезен, перестанет, так сказать, быть «минимально функциональным», т.к. полный комплект отчетности через него не сдашь.
И каждый год приносит какие-то фундаментальнейшие новшества. Так, если брать бухгалтерию и продажи, то: детальная отчетность по НДС, онлайн-кассы почти для всех и всего, маркировка, все более обязательный ЭДО, и др. А еще уважающая себя бухгалтерия должна уметь вести налоговый учет по ОСНО (в вариантах для ООО и ИП), УСН, сдавать отчеты по всему этому, плюс еще в статистику.
И во все это надо заложить кучу степеней свободы, т.к. исполнительные органы трактуют в каждом регионе нормы по-своему, а нормативные акты имеют склонность друг другу прямо противоречить по одним и тем же вопросам так, что провести учет с минимумом рисков невозможно — вас обязательно найдут за что вздрючить. Поэтому пользователи на местах предъявляют совершенно различные требования к продукту.
И это все относится почти к каждому предприятию, а я еще не беру сложные случаи типа лизинга, факторинга, ЕГАИС/ЛЕГАИС, и т.п.
И в таких условиях — переосмысливай, не переосмысливай подходы, все равно конфигурация будет представлять из себя кучу и сильно и слабосвязанных архитектурно различных модулей (что общего между лизингом и интеграцей с онлайн-кассами?). И будет 15 временных таблиц в запросе, потому что сборка какой-нибудь отчетности по страховым взносам требует залезть почти во все модули учета, включая кадровый, зарплатный, добавить ПДН-ы, развернуть это все по периодам, перегруппировать, и т.п.
Кстати, обратите внимание — вменяемых конкурентов прикладным решениям 1С мало, ИМХО, потому что такой вот огромный, но «минимально требуемый» объем функциональности, вкупе с регулярными обновлениями, в коробке, и за выносимые деньги, разыскать невозможно. И войти в этот рынок теперь тоже, т.к. объем инвестиций в готовый минимальный продукт просто какой-то нереальный, что конечно же скажется на конечной стоимости, либо отсечет даже попытки начать.
А если серьезно — наверное Вы правы, но я сам не могу оценить по сути. Из всех типовых конф меньше всего всегда вмешивался в код именно ЗуП/ЗиК и их модули в УПП/КА. Во-первых, вообще не люблю трогать типовой код. Во-вторых, реже всего требовалось. В-третьих — страшно.
С отладкой сложно во всем 3-м поколении конф. И текст запроса по кускам склеивается на коде, и временные таблицы гоняются через стек в 20 вызовов. Я даже себе расширение сделал специальное, в котором модуль, экспортная функция которого мне из МВТ извлекает и возвращает содержимое временной таблицы — для анализа в калькуляторе отладчика.
Но сам по себе, допустим, запрос из 15 временных таблиц для зарплатно-кадрового учета — вполне норма (с точки зрения написания своих отчетов и доработок), т.к. там куча мест (регистров и справочников) где лежат НДФЛ, страховые взносы, сама зарплата, кадровый учет (с его постоянными и временными переводами), и все это очень сложно организовано, и сложно соединять Бывает, сам напишешь что-то, ОТКОММЕНТИРУЕШЬ как можешь, а через год усомняешься в том, ты ли это писал, и был ли при этом трезв.
Но если бы Вы могли выразить мне мнение по паре вопросов общего характера, как раз по БСП, которые не дают мне спать, то я был бы очень признателен. Не знаю только, уместно ли задать на форуме, или лучше в личку.
Законодательная база такова, что как только расчет зарплаты и кадровый учет выходят из простого случая «Оклад + премия каждый месяц, 1 раз в год отпуск, а свои больничные пусть сотрудник засунет себе в...», хочется застрелиться под столом еще даже не открыв программу, потому что совершенно непонятно как обсчитать все это даже на бумаге, и не подставиться хоть каким-нибудь местом.
Команда 1С в этом плане выкручивается как может, и ухитряется предъявить не только достойный работающий продукт (не без косяков, ес-но), но еще и как-то предугадать развитие крайне волатильной и безумной законодательной базы и заложить некие степени свободы, чтобы через полгода конфигурация не перестала соответствовать вообще всему (ну это если мы отбросим теорию заговора, что собственники 1С лоббируют развитие бизнес-законодательства в интересах бесконечного развития семейства продуктов 1С).
Вопрос, как она написана внутри и куда, вместе с кодом типовых конф, развивается.
Очень избыточна, очень лапшеобразна. Комментариев, хотя бы намекающих, почему на достаточно простое действие надо 500 строк кода и стек глубиной в 20 вызовов (для разборки в котором нужен коньяк), крайне мало (нет вообще). Документация не очень хорошая, и материалов в открытом доступе тоже особо нет. А асинхронность вызовов превратило реверс-инжиниринг существующей кодобазы типовых конф (чтобы понять КАК это работает), и отладку, вообще в лютый ад.
Когда же начинается специфика (редко встречающиеся участки или сочетания учета, или особые пожелания клиента), все, конечно, становится немного сложнее.
В принципе, и простой и сложный клиент платят за продукт и за подписку на 1С одинаково, с коммерческой стороны — незачем перенапрягаться. Ну и, конечно, всем не угодить. Ну и армию подрядчиков тоже надо подкармливать. Ничего личного, чисто бизнес.
Заказчики полагают меня неплохим спецом, хотя я сам не склонен переоценивать свои навыки. Но когда разбираюсь в коде типовых конфигураций и БСП, у меня всегда возникает столько вопросов… столько вопросов… к разработчикам прикладных решений… и людям, которые их контролируют… А в этой статье почти все ответы даны. Вот прям по пунктам моих вопросов.
Они (ответы), конечно… более цензурны, чем я сам себе отвечал, но в целом процесс соответствует ожидаемому. Хотя бы теперь понимаю, почему так. Мне теперь будет чуть проще жить и относиться к этому.
Спасибо, было интересно. Поздравляю, что «вырвались из Омска», и удачи на новом поприще.
Хотя я это и читал уже ранее, просто, похоже с тех времен стал старше, и релевантность материала опыту резко повысилась. Короче, тогда было менее весело.
Вас извиняет только то, что от слез, похоже, прошел конъюнктивит.
Что касается БУ с НУ, то тут еще есть несколько НУ — НУ по налогу на прибыль, НУ по НДС (особенно в ряде случаев, когда его надо восстанавливать в разрезе материалов при льготной реализации продукции), НУ по НДФЛ, НУ по страховым взносам, НУ по налогу на имущество (целый контур наслоений льгот и разных ставок, с поправкой на специфику по регионам). Если УСН 15%, то НУ по УСН, или даже НУ у ИП на общей системе налогообложения (свят-свят).
И для каждого надо отдельную голову иметь.
Хочется куда-нибудь забиться под кровать и застрелиться от обилия нормативной базы.
С другой стороны, ERP-подобные системы пишут опытные люди, и если они предложили в системе какой-то готовый процесс, то его следует хотя бы рассмотреть и примерить на себя. Возможно не зря так сделали.
То, что Вы написали в цитате, когда оно в единой базе, это как раз продукт хорошей автоматизации и грамотного выстраивания процессов, и вообще 1/3 внедренной ERP.
По моему опыту, пока все живут в зоопарке разных клочковых баз (как я писал выше), такой проблемы нет.
Как только сажаешь бухгалтерию и профильные службы в одну лодку (что естественным образом должно произойти при внедрении ERP-подобной системы — прямо, или косвенно, через выгрузку) — начинается: «Да как это так, что номенклатуру кто-то заводит? Да она должна прописываться строго как в приходной накладной!».
Часто, при этом, бухгалтерия (как структура, достаточно близкая к руководству, наиболее авторитетная по возрастному признаку, да еще и обладающая опытом использования «самых современных» программ автоматизации) таки продавливает свою позицию (вбивать, как в накладной), чем погружает оперативку в жесточайший хаос.
Каждый проект, когда приходится ломать эту концепцию, примиряя их между собой (а по факту — ломая бухгалтерию в пользу внятного классификатора, удобного оперативщикам, и поручая его ввод последним), седеет очередной клочок волос.
Даже сложился отличный сигнальный критерий. Смотрю, как в бухгалтерской базе заведены хоз и канцтовары. Если карандаши, ручки, ластики вбиты по артикулам, а бумажные стикеры по размерам — то обычно все, это полярный лис. Это будет больно. А если просто «карандаш», «ручка», «стикеры», или даже «канцтовары на сумму» — то договоримся и по метизам.
По остальной части Вашего сообщения у меня нет комментариев, я хотел только поделиться вышеизложенным.
Просто на фоне слез умиления застлавших мне глаза, ну и учитывая, что я сам никогда не подвергал сомнению необходимость внедрять ERP-системы (при разумном подходе и известной целесообразности), не акцентировал на этом свое внимание.
Самому случалось писать статьи, в которых часть, посвященную плАчу Ярославны я излагал, а на то, как надо делать правильно — времени не оставалось.
Ну, автор, как я понял, не имеет ввиду конкретное предприятие, он просто широкопрофильный консультант, выложивший статью в промо-целях для абстрактного случая, хотя и основанного на чьем-то реальном опыте.
А вот то, что руководство предприятий часто совершенно не понимает своих бизнес-процессов (и не хочет даже вникать), не может контролировать подрядчика по внедрению ERP, а подрядчик не пытается вправить предприятию мозг на уровне процессов, схем и решений, а пытается продать красиво завернутое «ничего», что-то сделать наобум и побыстрее свалить, прикрываясь бумажками, опрометчиво подписанными заказчиком, а сотрудники не подчиняются и саботируют (это уже реже, и не так важно, и скорее следствие), что по итогу приводит к плачевным итогам, — по моим наблюдениям, чуть ли не норма. Какая-то чертова системная ситуация просто. Позитивных примеров на порядок меньше.
Правда это лишь мои наблюдения, ограниченные выборкой из нескольких десятков предприятий в небольшом регионе ЦФО и немного в соседних. Поэтому статья показалась мне релевантной проблемам, которые я разгребаю, потом, каждый день. А может это просто место проклятое…
К автору-то, может быть и так очередь, он к стулу не прирос и, если что уволится, чтобы за эту богадельню ответственность потом не нести, но кейс пополнится такими вот ситуациями.
И хотя стиль изложения конкретно этого текста, конечно, забавен, направлен на PR, а для специалиста пестрит прописными истинами, какой-либо неправды тут не написано (ИМХО), и суть достаточно понятна для ЛПР. Может быть одному из них хоть такой «научпоп» нагуглится на глаза во время разборов протоколов совещаний.