Comments 882
адепт секты кубердокеровгитсиайсиди кидает камни в адептов секты 1с
камни
какашки
Ну да, адепт секты КуберДокеровГитСиАйСиДи обвиняет адептов секты 1С в ритуалах на древнем языке с запахом бухгалтерии и проводками на дебет/кредит. Один автоматизирует деплой через YAML, другой — отчёт по форме №Т-51. У каждого своя боль, своя вера и свой консольный шаманизм.
Но давайте честно: если бы 1С поддерживала Helm-чарты и деплой в Kubernetes, вы бы её уже в прод выкатывали с label'ами legacy: true, и тихо рыдали в corner office над logs. А так — просто другой культ. Тоже с мучениями, но с душой.
Мир всем сектам. Главное — не забывать, зачем всё это.
В 1С это были бы "штурвальные карты" на русском языке :-)
Бизнесу пофиг на то, как автоматизируется деплой. А за не вовремя сданный отчёт ф.666 могут вздрючить по самые помидоры.
А чего за такая секта 1С? Весь 1С это просто запоздалая калька с Lotus Notes/Domino, даже егойный LotusScript утянули. Обычный проприетаный монолит.
"А чего за такая секта 1С? ... Обычный проприетаный монолит. "
Что-то сразу ассоциации с группировкой "Монолит" из S.T.A.L.K.E.Rа
P.S. Извините - совсем не в теме. Просто мимо проходил.
P.P.S. Мне показалось или? Автор камушков в 1С накидал, а решение-то какое? "Есть конкретное предложение: надо что-то предпринять!" ?
Мой склад в голову пришел
Который (ВНЕЗАПНО) на 50% принадлежит 1С (см. выписки из ЕГРЮЛ).
Их много. Как микробизнес, видел кроме того Эльбу, Мой Бизнес, BC-Бухгалтерия...
Мой Склад (как и прочие Эльбы) куда менее универсален, чем 1С. Он в первую очередь заточен на торговлю, услуги (или сочетание услуги + торговля) в нем поддерживать не очень удобно.
Ну и регламентированная отчетность (те самые 100500 форм в 200 разных госслужб) тоже сильно отстает.
P.P.S. Мне показалось или? Автор камушков в 1С накидал, а решение-то какое? "Есть конкретное предложение: надо что-то предпринять!" ?
Есть конечно и уже давно. Вот, например, открытая и бесплатная платформа : https://habr.com/ru/companies/lsfusion/articles/707286/
И на ее основе открытое и бесплатное решение для небольшого бизнеса : https://mycompany.lsfusion.org/ru
Спасибо, за ответ! (И предыдущим товарищам, тоже!). Но мне думается, что если бы это было бы решением, не было бы самого вопроса статьи (она ведь не надумана?). Вероятно, есть проблемы в альтернативных продуктах или в методиках их продвижения на рынок (а может и сам рынок для этого не созрел, но, как я уже говорил, я тут -"мимокрокодил", не мне судить). Ещё раз, благодарю.
Половину статьи прочитал в захлеб - хейт в сторону 1с засчитан. Вы как автор хорошо описали одну сторону медали, но не удосужились её перевернуть и посмотреть на неё с другой стороны, сравнить с конкурентами, и вообще предложить какое-то решение замену.
Ваше просто "давайте все выкинем потому что тут нет докера" - увы, это не решение. Решение нужно в стиле - вместо 1С давайте напишем свой аналог на докере, итд итп. Но дальше если начать копать, то вдруг окажется, что современная бухгалтерия (за 30 лет изменений в налоговом законодательстве) стала очень сильно запутанной. Тебе нужна не просто бухгалтерия, а ERP система, с кууучей всякой самой сложной херни.
Касательно конкурентов сразу вспоминается гигантский и ужасный SAP. Его использует "та часть света которая никогда не слышала про 1С". Так вот, если вы им скажете про SAP, то они сразу все поймут и пойдут плакать вместе с вами.
Такая вот судьба у Erp систем - они огромные, они ужасные и очень старые. На них висит огромный вендорлок, они стоят огромных денег, они учат и выдают сертификаты специалистов. Ими чертовски больно пользоваться, а сопровождать ещё больнее.
Upd: ещё отдельно не рассмотрен вопрос бухгалтеров. "Они ПРОСТО привыкли". Нет. Вы даже не представляете, сколько бухгалтеров противилось и до последнего все нулевые не хотело идти в 1С. Все делали на бумаге! Представили? А теперь представьте, что десятки тысяч бухгалтеров должны сначала получить бухгалтерское образование (желательно высшее), знать все эти нюансы бухгалтерского и налогового учёта, которое каждый месяц меняется и обновляется. Цена ошибки - миллионные штрафы. И вот во всей этой суматохе и огромного количества информации приходят ИТшники и предлагают выкинуть на свалку 1С, к которой они кое как привыкли и более менее понимают как она работает. Вместо неё предлагается что? Хмм, пока ничего. Подождать пару лет, и привыкать, учить и переучивать десятки тысяч бухгалтеров, ведь в 1С нету докера)
Да. Разговоры про докер... А попробуйте запихать SAP в докер. Предложите микро , малому, и даже бизнесу Axapta или Dynamics ... ну-ну... Расскажите, что "все будет хорошо" если внедрить любую CRM из списка "15 бесплатных CRM". Старый, архаичный язык против некоторых Java frame work, в которых разбирается 100 человек в мире и 2 человека в РФ... о есть ещё R-Keeper (да знаю это только фронт офис и CRM) с его "великолепными" скриптами на как бы паскале, "совершенной'" модульностью и офигенной "скоростью" ...Все это прям предельно современно? Любой сложный бизнес-софт будет сектой , потому как обязан быть обратно "совместим" с кучей установок, которые работают десятилетиями, требованиями ФЗ. А там в "посвященном мире, где не знают про 1С" сколько компаний молятся на код который написан на COBOL 40+ лет назад? Да 1С это полносвязанный монолит, это его проблема, но , что у всех случилось счастье от какой-то другой системы на микросервисной архитектуре с кластером Kubernetes, Kafka, ClickHouse и ... MongoDb ... и, что там не будет зависимости от разработчика, а поддержка этого решения будет дешевле 1С, там со временем не появится своей микросекты адептов, которые знают то чего нет в документации или вообще читали эту документацию, сам факт существования которой уже достижение, а ее внятность и адекватность текущему состоянию определит "святость" разработчиков? Низкий порог входа... Для hovno кода порог всегда низкий, а том числе и в 1С, да там его больше, так как дисциплины меньше, а платформа даст запустить практически, что угодно) и через пару месяцев "Я разработчик бизнес решений". Но когда мне в моем бизнесе потребовался бизнес софт, что мне было выбрать? Все выше перечисленное? Ага ))) и все мои коллеги которые Kubernetes, Kafka, ClickHouse, noSQL, C++, C#, Rust, backend, embedded developers сказали: "чё 1С?", то я в 53 (тогда) года в него влез и разобрался, но до нормального кода, с пониманием , почему так, прошло 2 года, так же как и для любого другого языка.
Не десятки тысяч бухгалтеров, а сотни тысяч я думаю
Предлагаю пытливому читателю такое упражнение: заменям по тексту "1С" на "SAP" , переводим на английский и перечитываем
Они со своими докерами никогда не смогут и половины логики понять:) тем более куча изменений каждый день. 1с это больше про требования бизнеса, а не про технологии. Реально работающий десятилетями продукт, без которого было бы очень тяжко.
Абсолютно согласен. 1С - это про своевременную реализацию требований к формам отчетов и порядок их заполнения. Они всегда успевали вовремя все самые сложные вопросы налогового и бухгалтерского учета реализовать, даже когда еще ФНС не могла понять, что происходит (например, когда массово с ЕНВД на ПСН налогоплательщиков перекинули), 1С уже давала внятные варианты, не бросала бухгалтеров один на один с этим.
Это про понятные и здраво реализованные способы учета лизинговых операций, например, которые запутаны Минфином и ФНС донельзя.
И плевать директору, юристу и бухгалтеру, что там под капотом, если работает. А оно работает, как ни крути
Ваше просто "давайте все выкинем потому что тут нет докера" - увы, это не решение.
Мне кажется, речь тут не про выкинуть. Например в абзаце "Почему это рудимент" в 1 и 2 пункте написано, что конкретно можно было бы в теории сделать (сделать опенсорс). Уж как именно их заставить открыть код я не представляю.
вероятно, их нужно как-то в этом заинтересовать. а зачем оно им надо, если они и так монополисты? тут замкнутый круг: все привыкли работать в 1С, продвигать что-то новое не получится потому что бухгалтерия пошлёт вас нафиг, а самим 1С ничего менять не хочется потому что и так пипл схавает.
Они не "заинтересуются". Как-то лет 10 назад, когда сняли с продажи 7.7, кто-то то-ли спрашивал, то-ли просил Нуралиева выложить в открытый доступ код 7.7. И он ответил что-то в духе "мы что, самоубийцы?". Ибо тогда народ доработал бы саму систему с учетом 1с++ (включая имеющиеся классы), других компонент - и появилась бы открытая поддержка конфигураций под текущие требования, доработал бы конфигуратор (сделал бы опенконф штатной функцией) - и продажи восьмерки (в части УТ точно) упали бы очень сильно.
erp это не в законодательстве дело. А в том что многие бизнесы доросли. Что надо не просто фиксировать хозяйственную деятельность по факту, но и например бюджетирование нужно для планирования расходов и источников их финансирования.
Добрый вечер, вопрос конечно же не в конкретном докере, а в платформе 1С и в принципе построения архитектуры программы для бухгалтеров (как бизнесовой, так логической).
С конца 90-ых внедрял и сопровождал бухгалтерские, складские, финансовые я ещё под DOS, затем когда перешёл на этом же предприятии (ДО ВИНК) уже бухгалтером, участвовал во внедрении программы под виндовый интерфейс, и хорошо что это была не 1С (хотя тоже российская разработка). И для бухгалтера он действительно была более понятна, во всяком случае соответствует теоретическим аспектам бухгалтерского финансового учёта, который описан в учебниках и которому учат в вузах. Прекрасно понимаю о чем говорю, поскольку первое высшее факультет информатики и вычислительной техники, а второе - по специальности бухучет и аудит.
После этого работал на других предприятиях и всегда когда имел дело с 1С смотрел на нее через призму удобства для бухгалтера и сравнивал с той программой. Надо признать что сравнение всегда не в пользу 1С, а продуктов повидал много и УСО и УПП и других.
У меня ощущение в 1С нарочно не делают базовый функционал сразу как надо, как написано в учебниках по бухучету, чтобы пользователи ещё доплатили за допил до нормального использования. Если взять к примеру ОСВ по 10 счету, то оно не похоже на нормальную ОСВ которые повидал в других (в т.ч. DOSовских прогах). Причем это с самого начала существования 1С и продолжается эти несколько десятков лет.
Также когда то на заре своего существования 1С придумали понятие субконто, которого тоже нет в теории, и дальше видимо не могут от него отойти (это к странной логической архитектуре). Кстати ни одно из мне известных бух решений не использует такое понятие, все проги почему то обходились обычными счёт/субсчет/статья.
С упоминанием выше миллионов часов трудозатрат согласен, это к тому что можно сделать (и ведь делают) простые и удобные бухгалтерские программы.
А насчёт сложности бухучета, так он сейчас наоборот более упрощается, эволюционирует и сами принципы бухучета не считаю каким то сдерживающим фактором чтобы нельзя было создать удобную для бизнеса программу.
Если взять к примеру ОСВ по 10 счету, то оно не похоже на нормальную ОСВ которые повидал в других (в т.ч. DOSовских прогах)
а почему "нормальные" "в других", а не в 1с? И почему оборотка по 10 должна отличаться по другим счетам?
1С придумали понятие субконто, которого тоже нет в теории, и дальше видимо не могут от него отойти
Придумалли. Но тем не менее, это обычная аналитика по счету, котрая, например, есть в БЭСТе...
"Гигантский и ужасный SAP" управляет гигантскими и ужасными корпорациями. Порог входа туда высок и да, это больно. Про старые вы не правы. У SAP было и есть много передовых продуктов на протяжении всей истории от R/1 до S/4HANA. Сегодня это высокопроизводительная база данных, облачные технологии, блокчейн и ИИ.
У автора очень узкий взгляд на 1С
Файл можно получить по ссылке:
Соллерс.mp4
https://disk.yandex.ru/i/a8nMP_1vnaytlA
Вот здесь рассказывают, как автоматизируют автомобильные предприятия. Тут конечно много разного инструментария использовалось, но основа написана на 1С. Можно сказать, что его тут в качестве бэкэнда запользовали. И очень даже неплохо получилось.
А когда-то и ТурбоБухгалтера хватало)
@necros2k7 согласен полностью, по DOS ещё помню в Инфо-Бухгалтер работали и без каких-то усложнений обходились.
Автор не понимает различие между разными классами языков программирования. Есть такое понятие Rapid application development и языки под это проектирумые. В итоге с упорством предлагает тащить технологии из универсальных системных языков в прикладные. Стоимость разработки его не волнует. И да git в 1c тоже есть это 1с edt . Но автор не удосужился пробежаться по сайту 1с
При всей моей не любви к 1С, вынужден признать, что он прошёл проверку временем. Я помню как давным-давно, в конце 00х создавались open source проекты, которые должны были похоронить 1С. До наших дней, вроде, ни кто не дожил. Я сейчас даже их названия вспомнить не могу.
Ну и не совсем понятно с чем автор сравнивает. Например, если сравнивать с SAP, то там почти все перечисленные проблемы можно проследить.
Если сравнивать в плане бухгалтерской функциональности, то из конкурентов только Эльба на ум идёт, но она вроде только для УСН, да и давно она не отсвечивала.
Что бросается в глаза в посте, то автор оценивает систему с точки зрения разработки, а не конечной пользы, которую система причиняет. Тут с радостью соглашусь, работать с этим не удобно.
Согласен, 1С действительно прошёл проверку временем, и, как ни крути, до сих пор остаётся востребованной системой. Да, куча open source-проектов пыталась «убить» его в 2000-х — и где они теперь? А ведь некоторые из них могли бы быть и удобнее, и гибче, и технологичнее — но их просто задавили. Не по конкуренции, а административно, через проталкивание «своего».
И вот что неприятно — не когда программа становится популярной потому, что она нужна, полезна и удобна, а когда её искусственно вталкивают на рынок. Хочется, чтобы популярность была естественной — заслуженной, а не навязанной.
И да, автор поста явно оценивает систему с точки зрения разработчика. С этой позиции — да, больно. Хотя конечный пользователь зачастую свою пользу получает.
А кто давил административно альтернативные системы?
Я вообще трудно себе представляю бухгалтерскую систему в опен сорсе, от в очередной раз у налоговой или правительства зачесалось (а чешется у них постоянно) и вы не можете тупо печатать документы в новом обязательном виде, все аншлаг. Надо ждать когда же кто то умелый донесет это в систему. Либо искать своего спеца и платить за внесение изменений. Многие из доплативших не захотят комитить обратно т.к. заплатили.
Я вообще трудно себе представляю бухгалтерскую систему в опен сорсе, от в очередной раз у налоговой или правительства зачесалось (а чешется у них постоянно) и вы не можете тупо печатать документы в новом обязательном виде, все аншлаг.
А какое отношение это имеет к OSS?
Надо ждать когда же кто то умелый донесет это в систему.
Вообще, если это гос. система, то именно налоговая и правительство должны этим озабачиваться. Причём, достаточно очевидно, что эти адаптации и должны быть совершеннейший 146% open source. Подписанный open source.
В России сложилось очень необычное положение, при котором OSS невыгоден для государства. Если государственное предприятие создаёт OSS, оно потом не может окупить его выручкой.
Если государственное предприятие создаёт OSS,
То создание должно окупаться тем, что государство за это создание заплатило. А потом соответствующее ПО должно быть свободно доступно всем налогоплательщикам, на деньги которых это делалось (т.е. как минимум всем россиянам). Вот, NASA, кажется именно из такой логики свой софт выкладывает.
Но это увы, мечты.
Как правило, государство создаёт предприятие, чтобы получать от него прибыль и налоги.
Но это увы, мечты.
Да не переживайте, всё к этому идёт, если, конечно, Государство Российское хочет жить.
Посмотрим для примера на Роскосмос. Он очень хочет жить, поэтому продаёт фотографии, размещённые на своём сайте.
У вас какой-то взгляд через розовые очки на государство. В текущей политико-экономической обстановке государство будет драть 7 шкур со всех кого сможет, и ничего никому бесплатно не отдаст.
Вы описали программу налогоплательщик юл. Поработайте в ней.
Если государственное предприятие создаёт OSS, оно потом не может окупить его выручкой.
Почему? Что не позволяет зарабатывать на поддержке своего решения?
И действительно, почему Ростелеком не может получать прибыль от ПО Госуслуг, зарабатывая на поддержке этого программного продукта по заказам предпринимателей? Возможно, нет платёжеспособного рынка.
Во-первых, Ростелеком не разработчик ПО Госуслуг. Изначально разработкой занимался Энвижн Груп и получил за это вполне реальные деньги. Сейчас этим занимается РТЛабс. И тоже не бесплатно.
Во-вторых, с чего Вы решили, что Госуслуги - СПО?
В-третьих, тот же Сбер на своем gitverse выложил уже немало СПО. Например Сбертех вполне себе зарабатывает на обучении и поддержке своих open source продуктов. Значит всё же платежеспособный рынок есть?
Вот я и задаюсь вопросом, как получить доход от продажи Госуслуг, если выпустить их в опенсорс?
Сбертех умудряется зарабатывать даже на продаже портретов своего директора. Они очень ловкие!
Вот я и задаюсь вопросом, как получить доход от продажи Госуслуг, если выпустить их в опенсорс?
Напишите свой хелловорлд, опубликуйте на гитхабе и продавайте. Может кто и купит. )))
А если без шуток, то Госуслуги кроме одного государства никому не нужны. Слишком неудачный пример Вы выбрали. Да еще вооружившись демагогией принялись переходить от единичного частного к общему.
Сбертех умудряется зарабатывать
Получается, что Вы всё же согласились, что Ваше утверждение ложное:
Если государственное предприятие создаёт OSS, оно потом не может окупить его выручкой.
Сбертех окупает. Одного примера достаточно.
Сбер — акционерное общество.
Принадлежащее Фонду национального благосостояния России.
Ростелеком - тоже акционерное общество.
Вы путаете форму собственности с организационно-правовой формой.
Да, похоже, что вы правы. Я имею в виду, что коммерческая фирма может такое сделать, а государственная фирма не может, потому что выполняет заказы государства.
Вы опять не правы.
Деятельность, приносящую доход (внебюджетную деятельность) могут вести все типы учреждений, если такая деятельность отвечает целям создания учреждения и предусмотрена в его учредительных документах (п. 3 ст. 161 БК РФ, п. 4 ст. 9.2 Закона о некоммерческих организациях, ч. 6, 7 ст. 4 Закона об автономных учреждениях).
Например, бюджетные университеты и институты повсеместно занимаются коммерческой деятельностью.
Вы совершенно правы. Отсюда и возникает вопрос, как они смогут заниматься коммерческой деятельностью, если начнут бесплатно раздавать свой продукт через свободное ПО?
Обратите внимание, что бюджетные институты и университеты не передают свои коммерческие разработки в опен сорс. Не помню ни одного вуза, который передал бы в опен сорс даже (!) тексты и фотографии со своего сайта.
как они смогут заниматься коммерческой деятельностью, если начнут бесплатно раздавать свой продукт через свободное ПО?
Так же как и все - на обучении и поддержке. Хотя при этом еще community версия может стимулировать клиентов к приобретению enterpise версии.
Обратите внимание, что бюджетные институты и университеты не передают свои коммерческие разработки в опен сорс.
Вы опять заблуждаетесь. Для примера возьмем ВШЭ.
Точно так.
Ну это «артифекальное» состояние, связанное с Реставрацией. Думаю, за десятилетией-другое рассосётся. Инфраструктурные проекты не должны думать о прибыли, да и быть частными.
Расскажу вам былину. Как-то раз губернатор Псковской области приехал в областной музей и спрашивает у сотрудников: «Вы говорите, что в музее собраны огромные богатства, а почему же вы сами такие бедные? Почему вы не используете эти богатства для того, чтобы наладить коммерческую работу с клиентами? Нельзя всегда оставаться на бюджетной поддержке, надо взяться за ум и получать выручку».
Этот губернатор был человек смелый и искренний, поэтому всё сказал в открытую. Другие губернаторы люди скромные, они молчат, однако требования у них везде одинаковые. Надо взяться за ум и получать выручку!
Этот губернатор был человек смелый и искренний, поэтому всё сказал в открытую. Другие губернаторы люди скромные, они молчат, однако требования у них везде одинаковые. Надо взяться за ум и получать выручку!
Ещё раз — если Государство Российское жить хочет, то камеры под этих губернаторов уже потихонечку высвобождаются. А дальше будет примерно как с МО РФ. Ну либо придётся немножко умирать.
Это не какие-то особые губернаторы. Так принято везде.
Значит придётся это ломать через колено, либо умирать. Ну сажать будут не всех губернаторов, а только упрямых. Хотя не надо думать, что в 140 миллионной стране очень сложно найти замену меньше чем сотне управленцев.
По сути, вы предлагаете переменить всю бюджетную политику.
Тут одному-то управленцу уже 25 лет замены найти не могут, а вы про целую сотню.
Насчёт OSS не скажу, но ФНС вполне себе пилит 3-НДФЛ на деньги налогоплательщиков и выкладывает это приложение для свободного скачивания. Ничто не мешает той же ФНС пилить и систему для бухучета на деньги тех же налогоплательщиков (и хоть сто раз в день свои формы отчетности меняйте)
Бесплатное скачивание не означает, что у получателя есть какая-то свобода и какие-то права. Бесплатное скачивание не позволяет ни получить текст программы, ни распространять его, ни переработать его в другую программу.
Сделаю аналогию. В библиотеке вы можете бесплатно прочитать книгу, но переиздать книгу вы при этом не сможете.
а) Это недоработки, связанные с текущим моментом — Реставрацией.
Достаточно очевидно, что OSS этой ФНС выгоднее — среди пользователей наверняка кто-то найдётся, кто сможет найти источник ошибки и прислать патч. Или попросить знакомого.
Разработка софта ведь не является основной деятельностью — это только расходы, которые желательно минимизировать.
б) ФНС несёт определённую ответственность за этот софт, поэтому upstream и форк различаются очень сильно. Как бы не юридически.
То есть, тут лучше подходит модель открытого, но не совсем свободного софта. То есть, получается как раз модель библиотеки с бесплатным ксероксом.
А мы какую задачу-то решаем?
Если вести учет и сдавать отчетность, то почему нам не хватает дистрибутива прямо с сайта производителя? На кой нам понадобилось его распространять, если он прямо на сайте ФНС прекрасно сам распространяется?
Ну, а ежели задача в другом, например, обязательно залезть ручками, потому что NIH, тогда какая разница вообще: 1С, парус, госналогучетотчет.учу или ещё что, всё одно: пилить свое, ни с чем не сравнимое (но это и так никто не запрещает делать прямо сейчас, так и так руками за их ежедневными изменениями форм отчетности следить).
по правде сказать приложение чудовищно, без шпаргалок форму в нем заполнить невозможно. и да, уже как несколько лет оно ненужно, 3-ндфл можно на сайте заполнить.
Честный знак - этакая синекура для обобранных олигархов с вами не согласится. На этом можно делать деньги и не в госбюджет же их вносить...
Счестный знак это формула 10коп государству 50коп олигархам, с точки зрения производителя маркированного товара это миллионы убытков-расходов, с точки зрения реализаторов маркированного товара это гемор с автоматизацией, того же 1С, где ФНС пытается контролировать jsin коды которых можно много раз распечатать и разрешительный режим это не спасает ибо 7 дней за которые должны проверятся чеки это безсмысленно, так как это бред. Пишу с точки зрения разработчика своего модуля для работы с Ч-З в собственной системе управления складом, торговлей, производством, доставкой разными ERP, CRM. Вот 1С версии 6 отличается очень с 7.7 и очень с 8 версией. Масштабируемость 1с ERP это золотое дно для внедренца) Рекомендую обратить внимание на no-code VisualData с его no-sql СУБД тут можно хоть что автоматизировать, кроме написания игр во 2 версии но при должном умении в 3 можно)
Вообще, если это гос. система, то именно налоговая и правительство должны этим озабачиваться.
На этом споры об опенсорсе в отчетности можно считать закрытым?
ПС. Строго говоря государство должно устанавливать стандарты отчетности, а никак не ПО, ПО каждый пусть выбирает по вкусу сам. И с установкой стандартов гос-во более менее худо бедно ни шатко ни валко справляется.
Вы почти всю отчетность можете руками вон в контуре набить. Можете даже выгрузку туда запилить по их апи скорее всего.
Стандарты публикуются, почти даже вовремя.
А желающих пилить забесплатно стандаризированные по государственным требованиям системы учета нет.
Потому что это не идеи генерить, а очень неблагодарный тяжелый ежедневный труд.
Вы почти всю отчетность можете руками вон в контуре набить.
Как в рекламе - берём предварительно обжаренное мясо... Конечно, любая секретарша "может набить руками", если кто то эти цифры где то посчитает. А вот где взять эти цифры? Каждая ячейка отчёта имеет под собой ЛОГИКУ её заполнения. И, что бы "набить руками" надо ещё как то посчитать эти цифры, "выдернуть" их из миллиона других согласно каких то правил, в этом вся соль. А правила эти не всегда формулируются корректно - где то какой то случай не "покрыт", а где то и противоречие зарыто. Для того и есть "комментарии к бух. учёту", в которых разные примеры расписаны.
Вот это и есть давление:
Какая бы у вас не была чудесная и прекрасная бухгалтерская программа, хоть опенсорс, хоть западная фирменная, хоть сами написали на Паскале или Расте - ПОФИГ.
Вот вам данные для импорта в 1С, и предоставьте отчет, по форме "мы вчера понапридумывали" (перенесли строки справа налево и добавили пустую колонку).
Вопрос, зачем понапридумывали новую форму, и почему в 1С она появляется чуть ли не раньше чем в очередном ППРФ - ну, то такое..
А кто давил административно альтернативные системы?
Э-э... не знаю, как это назвать, но помню во времена шестой версии этой самой 1С бухгалтеры жаловались, что Инфобухгалтер удобнее на порядок, но вот отчет на дискетке то ли в налоговую, то ли в ПФР надо нести именно в формате 1С, иначе тебя просто развернут.
И у пфр и у налоговой были свои форматы, 1С умела с разной степенью достоверности выгружать в них.
И если инфобухгалтер не умел, тут вопросы к инфобухгалтеру.
П.С. инфа верна для Ставропольского края 99-04 год.
У меня Москва, и годы, не соврать, 1996 - 1998.
В этой идее все бы хорошо, кроме одного. Подобные фокусы можно проворачивать только тогда, когда имеешь инсайдерскую инфу об особенностях формата, а сам формат либо меняется три раза в квартал, либо закрыт насмерть, да еще и обфусцирован всяко от реверс-инжиниринга. Ну, как довольно долго было с .doc, например. Только .doc разрабатывала частная компания Микрософт, с целью поддержания своей монополии - а форматы отчетов ПФР и налоговой?..
Потому как, извините, но нормальный формат никаких сложностей для конвертации не представляет и представлять не должен даже для очень средней руки программиста. И "написать удобную бухгалтерскую систему осилили, а конвертацию в требуемый формат - нет" - прохладна мне та былина.
Не могу уверенно говорить про РФ, но я в Беларуси сказки про "специальный формат для 1с" тоже регулярно слышал (и до сих пор слышу). Даже в местных приложениях для получения и отправки платежек в банк была кнопка "выгрузить в формате 1С". Сей "закрытый, инсайдерский, обфусцированный" формат, на практике был текстовым файлом (*.ini) с полной документацией по каждому полю и правилам заполнения. И назывался он так, только для того, чтобы тетушки-бухгалтера не путались, какую кнопку нажимать.
Вот буквально комментом ниже уважаемый S-type, кажется, поясняет, что такое инсайд в данном конкретном случае. Я склонен с ним согласиться. И да, первый вариант в моем комменте примерно это и подразумевал. Формат регулярно меняется, и ты знаешь, как он изменится - а твои конкуренты не знают.
Опять же, делая скидку на реалии другой страны, в те времена когда я этим занимался, часто бывало, что импорт/экспорт при измениях в формате файлов я делал раньше, чем он официально появлялся в поставках местных франчайзи (в т.ч. у оф. представительства 1С). Значит что-то с инсайдами у них было не так, ну или кто-то сильно преувеличивает сложность отслеживания изменений формата.
С другой стороны, жалобы на "законодательство поменялось, а в обновлении 1С это еще не учли" - регулярная боль типовых решений (независимо от страны и года наблюдения). Странно для 1С лоббировать изменения, а потом "подставлять" своих клиентов.
Так что мое замечание было скорее про "а точно там были инсайды, или кто-то объясняет свою объективную неспособность успевать за изменениями, недобросовестной конкуренцией" ?
Тут уже можно теряться в дебрях фрактальной геометрии (с)
И другая страна, в которой запросто может не быть таких плотных подвязок; и (если вы слышите до сих пор) другое время. Что в те поры отчетность менялась практически каждый квартал - это я помню. До этого самого 1С бухгалтерия отчеты сдавала на бумаге, распечатывая из, прости господи, ворда. И прибегая ко мне перед каждым отчетом, потому что форма поменялась, и перебить даты-числа в старом файле не прокатит, вот тут нужно подвинуть, вот тут добавить, вот тут убрать... Дикие были времена. И никакого нафиг интернета.
Точно ли были инсайды? Нет, не точно. Но если ровно одна программа все успевала, а все остальные так или иначе оказались за бортом - мне в такую победу в честной рыночной конкуренции, в РФ, да в этой области - верится, скажем так, с некоторым трудом.
Хотя истории с "ждем обновления, а то все поменялось" я тоже помню. Просто более поздние, образца скорее самого конца девяностых - начала нулевых. Тогда, впрочем, бороться было уже не с кем, конкуренты сидели в маргинальных нишах и не отсвечивали.
Ну а вот мы в СК в 02 сами сделали свою версию зарплаты, вместе со всеми выгрузками в налоговую и в пфр, или у пары фрилансеров тоже был инсайд?
Формы для налоговой в 1С часто правили еще до того как доезжал нужный патч от самой 1С, каким то образом бухгалтера сами занли, что надо подправить.
В общем мы жили в каких то разных мирах.
Ушел от 1С в 04 и счастлив )))
В разных, да. 1996 и 2002 - это реально разные миры.
Как р аз в 96-98 регулярно подправлял выгрузку из БЭСТа (он был ломаный, поэтому не обновлялся.) Откуда брал информацию об обновлении форматов - не помню. Вроде там был простой текстовый файл, с кодами строк.
Как я понимаю, там весь вопрос был в том, чтобы взять ее вовремя.
Возможно. Или же в том, что тогда значительная часть бухпрограмм были, хм, "цельнотянутыми". У 1с был уже свой канал дистрибуции и доставки обновлений, у других с этим было хуже (помню, как примерно в 92-93 БЭСТ критическое обновление перед самой сдачей отправлял самолетами, уж не знаю, с пилотами или с пассажирами).
Ну и я откуда-то брал инфу, интернета у меня тогда точно не было.
Когда у нас была 1С, нам дискетки привозили. Или бухи с дискетками ездили, чтоб я помнил. Но 1С точно была лицензионная. Бухгалтерский софт (и помянутый инфобухгалтер тоже) был единственным лицензионным софтом в конторе, это я помню хорошо.
А когда были бумажные отчеты, точно ездили бухи и привозили бумажный образец. Под который надо было ручками подгонять вордовские бланки.
Я о том и говорю - 1с начала практически сразу не только "делать программу" (каковая в виде 6.0 сильно отставала от конкурентов), но и "строить дистрибуцию".
Ну а бумажные бланки можно было покупать и заполнять и вручную, чуть не до 2010 года (я последний раз году в 2004 заполнял так баланс, а до 2010 - декларацию ИП)
А кто давил административно альтернативные системы?
Расскажу КАК задавили остальные программы. Работает бухгалтер со своей программулинной "*Бухгалтер" (ИнфоБухгалтер, ТурбоБухгалтер и т.д. и т.п.) , формирует отчёт, распечатывает, подписывает, ставит печати и ВОВРЕМЯ несёт в налоговую. В там ей объясняют, что буквально вчера отчёт поменялся, и по старой форме они отчёт не примут, переделывайте. Как делать по новой форме - мы вам не консультация, читайте соответствующую литературу... Бухгалтер звонит в фирму "когда будет апдейт, в котором будет эта форма"? Там объясняют "мы сейчас не можем сделать апдейт на программу потому, что в законе есть пара мест, которые можно трактовать двояко. Запрос в правительство отправили, ждём разъяснений." И всё. Проблемы бухгалтера - это проблемы бухгалтера. Она начинает судорожно обзванивать знакомых и выясняется что в 1С эта форма УЖЕ работает! Им ещё на прошлой неделе патч прислали с новой формой. Пару штрафов за не вовремя сданную отчётность (или сданную вовремя, но оказавшуюся не корректной), руководство ставит перед бухгалтером задачу "работать без штрафов", на что получает ответ "надо ставить 1C". Почему же в 1С всё знали, и делали быстрее, чем другие? Нет, не потому, что они гении, а потому, что они знали заранее, ведь они помогали правительству те самые законы разрабатывать. По сути, они сами эти формы отчётности создавали.
1С действительно прошёл проверку временем, и, как ни крути, до сих пор остаётся востребованной системой.
Он сам себе создаёт нишу, потому и востребован: если бы он не случился то российский бухучёт не был бы таким установленным законом адским кадавром, в котором разобраться можно только с помощью программистов конфигураций. "Благодаря" этому российские предприниматели в массе вообще не понимают того, что бухучёт нужен не для отчёта перед налоговой, а им самим - чтобы знать чем они, собственно, владеют. А генерация налоговой отчётности в бухгалтерии должна быть просто её побочным эффектом.
А если бы не случился "Консультант+" то законы не выглядели бы как патчи к патчам, типа:
"Внести в Федеральный закон от 7 августа 2001 года N 115-ФЗ "О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма" (Собрание законодательства Российской Федерации, [...сократил...]; Российская газета, 2025, 4 апреля) следующие изменения:
1) абзац второй пункта 1.2 статьи 6 после слов "оплатой жилого помещения и коммунальных услуг," дополнить словами "получением денежных средств специализированной некоммерческой организацией, которая осуществляет деятельность, направленную на обеспечение проведения капитального ремонта общего имущества в многоквартирных домах (далее - региональный оператор),";
2) в абзаце третьем пункта 1.4 статьи 7 слова ", созданных в организационно-правовой форме фонда в соответствии с Жилищным кодексом Российской Федерации" исключить.
Он сам себе создаёт нишу, потому и востребован: если бы он не случился то российский бухучёт не был бы таким установленным законом адским кадавром, в котором разобраться можно только с помощью программистов конфигураций
Опять телега впереди лошади и запах конспироложества...
Вы, конечно, не поверите )
(тут наверняка есть представители ряда компаний, которые хитро усмехнулись)
Кто знает - тот знает, кто нет - считает конспирологией
Усмехнулись примерно так же как те, кто считает, что на Луне не было американцев, а ковид - заговор против человечества
Случаи, когда в "Консультанте" исправление появлялось раньше, чем было опубликовано были
Ещё помню как однажды настоящий суд судил по редакции в "Консультанте", а не действующей - это было поводом для целого скандала. Это произошло как раз потому что первоисточником в виде 200 "патчей" невозможно пользоваться
А если бы не случился "Консультант+" то законы не выглядели бы как патчи к патчам, типа:
Т.е. наличие консультанта привело к формированию думы в том виде в котором она сейчас есть?
то законы не выглядели бы как патчи к патчам, типа:
Ну патчи и финальная версия — это два необходимых представления, как нас учит опыт работы с git. Нужны оба.
российские предприниматели в массе вообще не понимают того, что бухучёт нужен не для отчёта перед налоговой, а им самим - чтобы знать чем они, собственно, владеют.
Основная цель предпринимательской деятельности — заработок денег, несколько противоречит выдачи прозрачного отчёта налоговой.
Ну патчи и финальная версия — это два необходимых представления, как нас учит опыт работы с git. Нужны оба
Патчи пусть выходят, фиг бы с ними (это, допустим, формально обязательная форма изменений). Но почему они имеют тот же нейминг ("Закон...") и ту же нумерацию, что и сами законы?
Имхо, законы (сами законы, а не поправки) должны нумероваться в формате ФЗ-12345 (статус, номер) и не более того. А поправки к ним не должны называться законами - пусть лучше постановлениями ГД или как-то так - и нумероваться в пределах года, как сейчас.
Юридические документы пишутся языком, не допускающим двоякого толкования.
Поэтому получается вот так. И доработки - патчами, потому что закон и есть программа: если, то, иначе, либо, и/или.
ЕСЛИ <подпадает под норму закона> ТО <наказань> ИНАЧЕ <нет состава>
Поэтому получается вот так. И доработки - патчами, потому что закон и есть программа: если, то, иначе, либо, и/или.
Можно ставить подпись 'принято' либо под патчем, либо под новым текстом закона целиком. У нас возможностью использовать патч явно злоупотребляют, что цитата и показывает. Ну даже есть не хочется весь текст закона - можно же было полный текст измененных статей принять, а не это вот все, где его надо ручной работой воссоздавать. (diff тут не автоматизированный)
Закон обратной силы не имеет. Поэтому до этой поправки один закон, после даты этой поправки - другой закон. Но т.к. учетная программа работает с сущностями распределенными по времени и подпадающие под разные временные версии закона, то это и должно быть отражено в учетной программе по аналогии с патчами закона.
И AI, к слову, в будущем, не столько отдаленном, такие вещи будет расшивать несколько получше прогов, которым не хочется читать тексты таких законов.
Мне кстати тоже не хочется.
Поэтому до этой поправки один закон, после даты этой поправки - другой закон.
И?.. можно и цепочкой полных текстов оперировать.
И AI, к слову, в будущем, не столько отдаленном, такие вещи будет расшивать несколько получше прогов, которым не хочется читать тексты таких законов.
А можно без AI а нормальным алгоритмическим Version Control. Вот как с текстами программ. Хочешь - полное содержание смотри, хочешь - diff между любыми версиями. Хочешь - полный текст на дату...
А то что публикуют и принимают "после слов... дополнить словами..." - это, все-таки, издевательство, где лишь делается вид, что "должно быть доступно для человека, не снабженного спец-инструментами".
Я знаю закон, в котором написано: следует публиковать. А в публикующей программе есть галочка "не публиковать". Если эту галочку нажать, данные загрузятся в государственную базу данных, однако публиковаться не будут.
Откуда же тут возникло двоякое толкование? Разве так можно?
Юридические документы пишутся языком, не допускающим двоякого толкования.
Это не так
Юридические документы пишутся языком, не допускающим двоякого толкования.
С точностью до наоборот
А если бы не случился "Консультант+" то законы не выглядели бы как патчи к патчам, типа
Не факт - в печатном издании "для практического использования" всё равно правки были сведены в итоговый текст (первоисточники публикаций нужны не для того, чтобы с ними непосредственно работали - а потому, что неопубликованный НПА не применяется). Сейчас, впрочем, текст закона и без Гаранта/Консультанта можно получить в электронном виде в актуальной редакции.
Гарант и Консультант выиграли не текстами НПА, а тем, что они идут в "обработанном" виде - с гиперссылками для всех отсылочных и бланкетных норм на другие части самого себя и на другие НПА, а также всевозможные комментарии, справочную литературу и судебную практику.
Да, можно конечно всё это делать по-старинке, но на поиск всех этих связей уйдёт куча времени.
А всё потому, что одного лишь закона (или подзаконного акта) - мало для правильного толкования нормы права, нужно систематическое толкование нормы права, с учётом всех взаимозависимостей, взаимодействий, ограничений, исключений, определений и пр.
Ну и да, Гарант / Консультант имели очевидное преимущество перед печатной версией актуальной редакции - они появлялись гораздо быстрее. И, кроме того, могут показывать НПА в старой редакции на нужную дату - что важно, когда в споре применяется редакция, действовавшая в соответствущее время, а не в данный момент (и не вступившие в силу изменения тоже видно, что иногда тоже важно).
Так что в отличии от бухгалтеров, которым было "некогда осваивать эти ваши компуктеры, нам работать надо!" (и в лучше случае им "требовался программист для работы за бухгалтерской программой"), юристам преимущества СПС зашли довольно быстро, потому что очевидно повышали эффективность их работы даже если читать удобнее в распечатке, а не с экрана.
Кстати, забыли еще об одной теории заговора- "в законодательство специально постоянно вносятся изменения, чтобы заставить бухгалтеров работать на компьютере и т.о. продавать бухгалтерские программы" (тогда еще более одной)
Не факт - в печатном издании "для практического использования" всё равно правки были сведены в итоговый текст
Нет. Например
Закон СССР от 16 октября 1989 г. N 603-I "О внесении изменений и дополнений в Закон СССР "О кооперации в СССР"
Верховный Совет Союза Советских Социалистических Республик постановляет:
Внести в Закон СССР от 26 мая 1988 года "О кооперации в СССР" (Ведомости Верховного Совета СССР, 1988 г., N 22, ст.355) следующие изменения и дополнения:
1. В статье 19:
пункт 1 дополнить абзацем следующего содержания:
первое предложение пункта 4 изложить в следующей редакции:
2. Абзац второй пункта 3 статьи 28 дополнить предложением:
3. Пункт 2 статьи 40 после абзаца третьего дополнить абзацем следующего содержания:
Во-первых, современных СПС в 1989 году еще не было - Консультант появился в 1992, Гарант - в 1990, так что ваш пример наоборот, подкрепляет сказанное мной )
Во-вторых - это текст закона о внесении изменений в закон - такие законы были и в советское время, есть и в российское. Что опять подкрепляет сказанное мной )
В-третьих, вы сейчас смешали "публикацию нормативного акта" (которая и поныне осуществляется в соответствующих изданиях, потому что статья 15 Конституции) и "издание текста НПА в актуальной редакции".
Второе не является официальной публикацией НПА, в отличии от "Собрание законодательства Российской Федерации". Нахождение НПА в Гаранте/Консультанте - тоже не является его публикацией. Да, пользуются уже сведёнными текстами, суд тоже в решении не будет приводить всю цепочку изменений фрагмента текста НПА, а сошлётся на текст в актуальной для рассматриваемого дела редакции, взяв его из СПС, но тем не менее.
И в-четвёртых, согласно ст. 9 ФЗ 14.06.1994 № 5-ФЗ «О порядке опубликования и вступления в силу федеральных конституционных законов, федеральных законов, актов палат Федерального Собрания», Федеральный конституционный закон, федеральный закон, акт палаты Федерального Собрания, в который были внесены изменения или дополнения, может быть повторно официально опубликован в полном объёме.
Я ниже как раз ответил, что "патчи к патчам законов" были до появления справочных систем, и вполне себе печатались в газетах в таком виде. И официальным органом, НЯП, с 1991-го была Российская Газета (только для этого и покупал). Тексты "в действующей редакции, с учетом изменений и дополнений", чаще всего печатались в книжках-сборниках, выходивших периодически (или в разных вкладках в газеты, типа "деловой четверг" - емнип, наш региональный вкладыш в РГ). Но книжки выходили реже, чем менялось законодательство.
Забавное воспоминание - когда налоговая, первоначально занимавшая четверть этажа здания, разрослась до этажа (т.е., наверное, 1992-начало 1993), на первом этаже были стенды с вырезками "обновлений" законов, и приходилось при спорах выводить инспекторов из кабинета, подводить к стенду и показывать - "вот такие изменения!". Эх, дикие времена были (через пару лет эта налоговая уже занимала всё двухэтажное здание целиком, а в настоящий момент занимает еще и подъезд в 5-этажке, переделанной под офисы..)
Вы напутали с датами. Гарант под DOS я пользовался уже в 1990 году.
Эх, дикие времена были (через пару лет эта налоговая уже занимала всё двухэтажное здание целиком, а в настоящий момент занимает еще и подъезд в 5-этажке, переделанной под офисы..)
Мелковатая у вас налоговая, они порой специально под них построенное отнюдь не 2-этажное здание занимают :)
Я ниже как раз ответил, что "патчи к патчам законов" были до появления справочных систем, и вполне себе печатались в газетах в таком виде.
Потому что патч - тоже закон, а значит - должен быть опубликован, чтобы вступить в силу. Нельзя править закон "втихоря". В советское время было так же.
И официальным органом, НЯП, с 1991-го была Российская Газета (только для этого и покупал).
По 1992 были Собрание постановлений Правительства Российской Федерации (СП РФ) и частично Ведомости Съезда народных депутатов Российской Федерации и Верховного Совета Российской Федерации. С 1992 по 1994-й было Собрание актов Президента и Правительства Российской Федерации (САПП РФ), заменившее оба источника до 1992г. С 1994 - САПП РФ заменилось на СЗ РФ, плюс РГ указана официальным источником в законе. Дополнительно с 26.10.1999 - "Парламентская газета", дополнительно с 10.11.2011 - размещение на "Официальном интернет-портале правовой информации" (www.pravo.gov.ru).
По факту да, РГ с 1990 (основание) по 1994 публиковала принятые законы, но на счёт статуса как официального не могу сказать точно, т.к. ФЗ от 14.06.1994 № 5-ФЗ, очевидно, появился в 1994г.
Региональное и местное законодательство - выходят в своих источниках.
Но книжки выходили реже, чем менялось законодательство.
Это так, потому СПС явно давали преимущество своим пользователям за счёт оперативности и удобства. Даже если они "по старинке" распечатывали оттуда на бумагу (да и сейчас иногда ).
Впрочем, если бы вы начали вот с этого, а не с "нет" - я бы даже спорить не стал :)
Мелковатая у вас налоговая, они порой специально под них построенное отнюдь не 2-этажное здание занимают :)
Обычная районная 7447 Челябинска. Правда, сейчас они №26, уж не в курсе преобразований. Просто т.к. с автоматизацией учета впервые жизнь свела в 1990-м - можно сказать, "история творилась на моих глазах" (особенно с учетом того, что 8 лет параллельно был главбухом). И помню ее от одного кабинета "райфинотдела" (вроде даже еще не администрации, а райисполкома)...
В сверх упрощенном виде: текст из какого-нибудь Консультанта недействителен. Действителен оригинал в какой нибудь РГ. И весь набор изменений по очереди, опубликованный в той же РГ.
А если бы не случился "Консультант+" то законы не выглядели бы как патчи к патчам
Нет, это стандартная практика. И существовала она еще тогда, когда не только Консультанта не было (и только-только появился Гарант), а когда законы печатались в газетах, у абсолютного большинства бухов и юристов не было компьютеров (учет велся в бумажном виде). И даже налоговых инспекций еще не было, были "финансовые отделы при районных администрациях"
Нет, это стандартная практика
В этой федерации да. А вообще, в мире - нет.
<разглядывая британский сайт> Вообще некая склонность есть, похоже так делать.
"Textual Amendments" - это вот оно, вроде бы, и есть. Только у британцев этот эквивалент "Консультанта" государственный, как я понимаю.
И вообще весь текст как-то аккуратней написан. Он хоть и легалаз, но аккуратнее на пункты, подпункты и прочие ветки разбит,
А если бы не случился "Консультант+" то законы не выглядели бы как патчи к патчам
Нет, это общепринятая практика внесения изменений в законы. Иначе при любом изменении закона министерствам и парламенту пришлось бы обсуждать, принимать и публиковать полный текст документа. В таком случае, наоборот, пришлось бы делать «диффы к законам», чтобы хотя бы иметь представление, что там меняется.
А если бы не случился "Консультант+" то законы не выглядели бы как патчи к патчам, типа:
git diff стал доступен каждому юристу. Вот так Консультант+ несёт прогресс в массы.
А истоки вашего негодования - я не понимаю.
А истоки вашего негодования - я не понимаю.
Сам подход сложился из-за того что этот де-факто обязательный софт существует с давних пор. Этот софт давно встроен в систему, хотя де-юре ею не является. Существует он на таком "самоподдуве" без конкурентов, и благодаря этому иногда даже подменяет собой Закон
Элемент, как кусок 1С Предприятия - дальнейшее развитие платформы. Они даже интерфейс в очередной раз обновляют для визуальной бесшовной интеграции. Да, упор на франчайзи устарел и сейчас 1С начали менять рынок под свой SaaS, 1С:Фреш как пробный камень, МойСклад - как агент влияния. Кол-во необходимых спецов сократится очень сильно. Но разработка и модификация оказываются всегда быстрей на 1С, чем на других решениях, а для бизнеса время-деньги. И да, там есть devops как методология и она работает.
Никто не давил административно, вообще. Инфобухгалтер был не менее популярен, но где он сейчас? Ещё был Парус...
Я ковырял 1С. Дичь несусветная, у них в то время, наверно как и сейчас, одна таблица, в которой хранится всё. Доступ к данным через фильтры. Гомнокод написан кириллицей. Я не знаю, может что-то сейчас изменилось, но та система в 90-х которую я смотрел выглядела допотопно.
Во именно, "что ковырял", судя по "все в одной таблице". Ну а про доступ к файлам через фильтры это прям, что называется, отлил в бронзу.)))
В 1с конфигурация может быть локальной (на диске) или серверной. В локальной может быть и г*. Но нормально нужно ставить серверную.
А в серверной все данные хранятся в сторонней базе данных - либо MS SQL, либо postgresql. Там эти данные нормализованы - то есть не одна большая таблица. А мелкие таблицы из пар - ключ/данные
это называется "слышал звон, да не знает где он".
Конфигурация сейчас что в файловом, что в серверном варианте - хранится в БД. Просто файловая - имеет свой внутренний формат БД, и ограниченный объем. Данные в БД (что в файловой в своем формате, что в серверной) - хранятся в виде множества разных таблиц, соответсвующих объектам конфигурации. (и собственно конфигурация, с описанием объектов, форм, с кодом - это просто еще одна таблица (на самом деле несколько, и там хранятся конфигурации поставщика, текущая, сохраненная - но это не так важно)). И не обязательно данные нормализованы
Согласен, 1С действительно прошёл проверку временем, и, как ни крути, до сих пор остаётся востребованной системой.
Звучит примерно как "АвтоВаз прошёл проверку временем..." Где бы были АвтоВаз и 1С без "административного ресурса"?
как задавили? Ну если многие 1с воспринимают как приблуду для бухгалтерии.. ну еще зарплату считать. И возможно эти убийцы 1с как раз и пытались занять эти ниши? ну тогда понятно почему они не прошли.
1с - это не только про бухгалтерию. Стоит выйти за другие отраслевые решения - и сразу видно что 1с - это по сути конструктор любых систем. Точнее - это обертка над базой данных, с готовым сахарком под всевозможные случаи типа чтения файлов, составления документов, работы в интернете и т.д.
В 2000 никто с этой стороны не мог задавить 1с - он еще не развивался в эту сторону, а софт под всякие нужны был уже нужен. Так что как обычно убийцы выбрали не ту область
А ведь некоторые из них могли бы быть и удобнее, и гибче, и технологичнее — но их просто задавили.
Это какие? "Парус" вот был - неудобно, коряво и отвратительно в целом.
В начале 2000х хоть в Excel можно было еще учет вести, кстати, - гибче и технологичнее
И вот что неприятно — не когда программа становится популярной потому, что она нужна, полезна и удобна
Но .... 1С: Бухгалтерия нужна, полезна и удобна. Соответствует всем критериям
Ну есть как минимум Парус, тоже живой, часто его в гос. конторах видел.
на памяти БЕСТ-Бухгалтерия, Парус, Галактика.
Парус тотальная заточка на бюджет, где он очень уверенно себя чувствовал.
С Галактикой встречался при попытке внедрить ее в одной из компаний где я работал тогда еще 1С заклинателем, увы не смогли они ее нам продать, тотальное отставание от 1С было.
тотальное отставание от 1С было
Трехзвенная архитектура ("клиент"-"сервер приложений"-"сервер БД") в "Галактике" появилась в 2000 году, 1с 8.0 вышла в середине 2003.
Возможность внедрения в систему "Галактика ERP" расширений пользовательского интерфейса, написанных на C++, Delphi, Javascript, публикация доступа к системе через веб-сервер появилась в 2008. 1С "дошла" до подобного функционала только к 2013 году.
Хорошенькое такое тотальное отставание...
Что, впрочем, не отменяет своих чисто "галактических" приколов.
Деньги платят за решение проблем, не за архитектуру
Если бы "Галактика" не решала бы проблем, она бы не дотянула до сегодняшних дней. Как и "Парус".
Дотянули за счёт легаси
Пожалуйста дайте свое определение "легаси".
https://en.wikipedia.org/wiki/Legacy_system
в данном случае я имел в виду невозможность замены по следующим причинам:
Retraining on a new system would be costly in lost time and money, compared to the anticipated appreciable benefits of replacing it (which may be zero).
The way that the system works is not well understood. Such a situation can occur when the designers of the system have left the organization, and the system has either not been fully documented or documentation has been lost.
Retraining on a new system would be costly in lost time and money, compared to the anticipated appreciable benefits of replacing it (which may be zero).
Извините, но мимо. Я писал про платформенные преимущества, но Вы их не принимаете. "Галактика" в состоянии обрабатывать такие объемы данных, на которых 1С на том же аппаратном обеспечении просто "подыхает" (даже с КОРП-лицензиями платформы), потому что упирается в свой технологический потолок. Так что эффект от замены на 1С будет не околонулевым (как вы приводите цитату), а скорее уйдет в отрицательные величины.
The way that the system works is not well understood. Such a situation can occur when the designers of the system have left the organization, and the system has either not been fully documented or documentation has been lost.
И опять мимо. Вендор никуда не уходил. Более того, при внедрении своего решения вендор заставляет своих партнеров вести проектную документацию по внедрению, листы изменений и т.п. И эта документация хранится не только у партнера, но и у вендора, партнер обязан по условиям договора с вендором предоставлять ему (вендору) полные копии этой документации.
У 1С и Галактики 5 лет было совместное предприятие. Продаж нет, есть убытки.
"Платформенные преимущества" оказались не востребованы.
Не вижу предложений "переход с 1С на Галактику, вижу предложения "переход с Галактики на 1С"
У 1С и Галактики 5 лет было совместное предприятие.
Было. "30 июля 2018 года российские разработчики корпоративных информационных систем, фирма «1С» и корпорация «Галактика», объявили о создании совместного предприятия с равными долями владения. Основная задача созданного СП – более эффективно удовлетворять потребности предприятий оборонно-промышленного комплекса, которые считают целесообразным одновременно использовать системы «1С» и «Галактики»" (невозбранно скопипащено с TAdviser)
"Тогда же глава «1С» Борис Нуралиев напоминал о том, что с «Галактикой» ранее было сформировано совместное предприятие. Он отмечал, что предприятие должно упростить централизованные поставки и совместное использование модулей «1С:Предприятия» и «Галактики».
«Если в какой-то организации или в холдинге часть решений, считаете, лучше на «Галактике», а часть – на «1С», чтобы не возникало лишних «боданий», покупаете общую лицензию, выбираете уже по месту. Это должно существенно упростить и закупку, и государственную поддержку, - пояснял Борис Нуралиев." (оттуда же)
Т.е. Это была обыкновенная "прокладка"-"купипродайка". Ни о каком-либо обмене опытом, технологиями, выпуске совместного продукта и речи не шло.
Продаж нет,
Потому что "военщина" покрутила пальцем у виска и продолжила работать по старинке: покупая лицензии и услуги напрямую у вендоров, а не у "прокладки".
есть убытки.
Убыток в 97 тысяч при уставном капитале в 2 миллиона Вы считаете критическим? Черных, Красилов и братья Нуралиевы по миру пошли? </sarcasm>
"Платформенные преимущества" оказались не востребованы.
Расскажите это "Росатому", "Сбертеху", "VK Tech", "Транснефти", дочерним предприятиям РЖД...
Не вижу предложений "переход с 1С на Галактику, вижу предложения "переход с Галактики на 1С"
Этому явлению можно дать объяснение. Первое, порог вхождения в "галактисты" гораздо выше чем в "одинэсники". Отсюда и бОльшая трудоемкость разработки. Если "одинэсник" пользуется только языком 1С, то "галактист" должен пользоваться VIP, FastReport, ГалаГраф, Xafari (всеми этими компонентами разработки или по отдельности – все зависит от поставленной задачи).
Второе, это условия поддержки. Стандартно Галактика просит за поддержку в течение года 25% стоимости лицензий по их текущему прайс-листу, при этом в случае пропуска годового обслуживания (допустим год обслуживались, год пропустили, решили возобновить обслуживание на третий год) пользователь обязан оплатить стоимость пропущенного года. Простая арифметика показывает, что если конечный пользователь не будет в течение трех лет оплачивать сопровождение, то на четвертый год он за поддержку заплатит как за стоимость новых лицензий. А лицензии у Галактики стоят довольно таки серьезно. По такой же модели в России работал и SAP A.G. Знаю, что и 1С работает по такой же модели "штрафов", только у 1С "штрафы" более вменяемые, чем у Галактики или у SAP (но это наверное пока "вменяеиые"). Так что разруха тут в головах, а не в платформе.
Ну и про переходы на 1С. Лет 6 тому назад одна "дочка" 1С и ВАЗ заключили контракт на внедрение "1С: MDM" с целью заменить заводское решение, написанное на Java + Oracle Database. Сумма подписанного контракта составила пол-миллиарда рублей (по тогдашней покупательной способности). И, знаете, я не увидел в прессе каких-либо победных реляций. Более того, по моим данным, полученным от сотрудников официальных дилеров ВАЗа, связка Java + Oracle Database до сих пор является основной для MDM ВАЗа. Другая история – это про Московский метрополитен, который решил перейти с SAP/R3 на "1С: ERP". Но тут надо ждать октября месяца этого года (по условиям госконтракта работы должны быть выполнены к этому сроку).
Этому явлению можно дать объяснение.
Т.е. если подвести итог объяснениям, получается, что 1с для бизнеса выгоднее. ч.т.д.
Т.е. если подвести итог объяснениям, получается, что 1с для бизнеса выгоднее. ч.т.д.
Какую выгоду получил ВАЗ от попытки внедрения "1С: MDM"? Если вы про порог вхождения, то Вы считаете сиюминутную выгоду, а не совокупную стоимость владения. В совокупной стоимости владения 1С находится на том же уровне, что Галактика/SAP/Microsoft Dynamics, а в некоторых моментах начинает проигрывать из-за того, что упирается в свой технологический предел.
Если пойти немного дальше, то возможности связки SQL и какого-нибудь языка программирования ещё более безграничны.
Однако многие почему-то покупают уже разработанные кем-то продукты, оставляя потенциальные возможности без внимания
В том была и проблема, как сейчас помню они и пытались продать платформу, мол смотрите у нас 100500 срезов, а у 1С только 100. Смотрите у нас 3 уровневая архитектура, а у 1С нет. В то время как 1С смотрите вы получаете приложение и в нем все есть, что надо для работы.
В этом и есть плюс и, одновременно, минус "Галактики" – для внедрения нужно выбрать из 100500 срезов "из коробки" только необходимые 100 или 500. А этот процесс может растянуться на пару-тройку месяцев из-за согласований с заказчиком, реализацией на Viper (или на другом языке программирования) силами внедренца/программистами заказчика если существующие разрезы "из коробки" не устраивают заказчика, или реализацией через Atlantis (тут уже сам вендор может подключиться) .
В то время как 1С смотрите вы получаете приложение и в нем все есть, что надо для работы
Если бы это было на самом деле, то не существало бы франчайзинговой сети 1С (и туевой хучи фрилансеров), которые занимались бы не только продажей лицензий (установкой обновлений, консультированием пользователей).
Не, там реально есть почти всё (т.е. типовым функционалом покрывается ну, пусть 90-95% типовых потребностей типовых пользователей, коих тоже процентов 90-95). Вопрос в том, как это покрывается.... Иногда кажется - уж лучше бы не делали вообще, чем сделали так, как сделали... Ну и плюс "в каждой избушке свои погремушки", т.е. конкретные бизнес-процессы построены у всех по-разному, вот и идет кастомизация. Ну а нагруженные системы - это вообще отдельный разговор
БЭМБИ ещё была, где-то дискета лежит
Инфобухгалтер.
Как раз с точки зрения разработки автор и не оценивает, потому что не видит или сознательно замалчивает главное - скорость разработки проекта произвольного хозяйственного учета. Она в разы больше типичного sql-ного. Кто не работал в обоих этих мирах, ни сможет оценить новаторства 1С, которое еще наличествует, несмотря на вот уже как 15-летнюю стагнацию в тупике. Подробнее я изложу на уровне статьи в мере, заслуженной автором
Я даже помню один из таких. 1L назывался. (Угадайте подо что должен был мочь работать? ;-)
Это не 1С прошел проверку временем, это время остановилось
Технологии не живут сами по себе, они живут в контексте человеческого общества. Возможно, что ригидность мышления является отгадкой вопроса живучести, а не технические характеристики.
Я сейчас даже их названия вспомнить не могу.
Я вспомнил один - Парус. Погуглил - он вроде живой, хоть и не опенсорс
@aikus использовал как бухгалтер Lexema, отличная система для пользователя, намного удобнее чем 1С.
@aikus использовал как пользователь систему Lexema, отличная, гораздо удобнее чем 1С.
ой, как все черно, сколько букав, и все для хайпа.
Никто не тешит себя иллюзией относительно 1С и соответствия новым технологиям. Но 1С - это продукт для выполнения ряда бизнес-задач, и пока он их выполняет, он живой. Еще раз повторю - он их выполняет. Не нужно стигматизировать разработчиков, которые работают в среде 1С - они выполняют бизнес-задачи, и успешно. Колесики экономики крутятся. Работает? Работает. Ради чего надо это "вотпрямщас" взять и от всего отказаться? Отказаться так сразу не получится. То, что сама компания 1С не собирается модернизировать платформу (возможно, что ее и не получится безболезненно модернизировать), прискорбно, но повторюсь. что не получится и от этого отказаться, а главное - заменить нечем. К чему тогда этот глас вопиющего?
Про интеграцию с государством - вы, автор, вообще слышали звон, но не знаете, где он. Это не государство требует 1С, это в 1С документооборот кастомизирован под требования государства. Нормальная ситуация - купив тот же SAP, потом будешь долго вжикать напильником, чтобы получить те формы отчетности, которые в 1C есть уже в коробке. А потом вдруг введут санкции, и останешься с тем же устаревшим продуктом, но видимо, душу должно будет греть, что "зато не 1С"?
SAP как платформа, к вопросу, тоже сильно не новая, и тоже устаревшая. И требуемого вами функционала там я лично не наблюдал, может, неглубоко погружался, но всяких глупостей и устарелостей напихано практически в любую платформу, предназначенную для учета движения материально-денежных средств, особенно историческую. Потому что очень сложно перешивать на сильно новые решения сотни тысяч предприятий, на которых крутятся огромные средства, задача эта совсем не тривиальная.
И подходить к вопросу в столь шутовской форме - не сильно правильная позиция. Проблема с 1С есть - платформа устарела, но заменить нечем. Пока что ничего схожего по функционалу нет. Я выбирал и сравнивал системы WMS, которые крутятся на российском рынке - увы, но выбрать можно только с 1С-овской платформы, все остальное не годится под требования среднего склада, или стоимость покупки, внедрения и поддержки сильно больше.
Ни SAP, ни Oracle, ни Microsoft тогда сюда особо не спешили, а западные решения стоили как крыло от Боинга.
а что из перечисленного - не западные решения?
а как это в 90-х весь софт сидел на пиратских субд оракл пиратских виндах и офисе, а вот учетные системы видетели.... дорого :)))
а что из перечисленного - не западные решения?
Автор наверно хотел сказать, что в начале 90-х западные компании не создавали местных представительств, не предлагали локализованный продукт с учетом платежеспособности аборигенов, и не создавали местную техподдержку.
А "западным решением" он назвал приобретение продукта на общих правах, и получение техподдержки из-за моря, и на заморском языке. Это была серьезная проблема, при том что тогда, из-за распада СССР, нормального интернета в стране не было.
вообще-то word 6 для windows (3.*) был не просто русифицирован, а даже имел совершенно легальный встроенный (притом сторонний) российский spell-checker небезызвестного господина Ашманова.
Сделать перевод менюшек и добавить язык в спелл-чекер - на несколько порядков проще, чем создать и, главное, поддерживать актуальной конфигурацию чего-то типа SAP для российского законодательства.
Причем тут адаптация SAP? Я возражал на отсутствие техподдержки и русификации ПО западными компаниями в 90е (безотносительно бухучета, так было сформулировано замечание).
Что касается SAP, то посмотрите на историю ныне покойную ERP "Галактика". Её создали раньше, чем SAP распространился в России.
Кроме того, SAP так устроен, что его из коробки невозможно где-либо внедрить без серьезного реинжиниринга бизнес-процессов компании вне зависимости от происхождения. Кроме того, бухучёт - это мизерный кусок функционала в ERP-системе.
Spellchecker был не просто "добавлен" в word, а сделан специально под него. Хотя, пример несколько не в тему.
Сейчас все решим: <имя нейросети> перепиши платформу 1С на Rust, Go, Java, Python(нужное подчеркнуть), сделай ее модульной, многопоточной. Сервера нейросети подняли температуру отдельно взятой страны на 1 градус, но как то справились. Встречайте 1$
Давайте посмотрим еще глубже. Что такое вообще бухгалтерия? Это движок БД, рассчитанный на бумажный носитель. Все эти проводки, шахматки, дебиты, кредиты и прочие сущности, придуманы лишь для того, чтобы удобнее было отражать хозяйственную деятельность в амбарной книге, легче искать ошибки и составлять отчеты.
Бухгалтерия стала совершенно не нужна с появлением компьютеров и реляционных баз данных, но легаси движок потащили в компьютер и стали в нем симулировать амбарную книгу, потому что "бухгалтеры так привыкли" - это и было главной ошибкой.
Вы ошибаетесь. Бухгалтер это в первую очередь тот кто соберет бумажки с подписью, которая означает что вот конкретно этот человек взял ответственность за деньги/товары/услуги на себя и распишется в итоге своей собственной ответственностью за все операции сам.
Мир он таки далек от розовых фантазий за экраном и отвечать/сидеть за ошибки придется не виртуально.
Не соглашусь с вами, что бухгалтерия утратила свою актуальность с появлением компьютеров. Что вы поимели ввиду под бухгалтерией? Проводки туда-сюда? Это так называемый принцип двойной записи: откуда ушло и куда пришло. Изобретен пять веков назад в эпоху Возрождения. Опубликован Лукой Пачиоли. Иллюстрировать помогал сам Леонардо (по памяти привожу, может Леонардо и ни причем: проверьте в Вике). Без двойной записи получится как энергия ниоткуда. А это уже, батенька, закон сохранения энергии, следуемый из однородности и изотропности пространства (см. Теоретическая механика, том перший). На самом деле бухгалтерский учет это иное название хозяйственного учета, а от последнего в индустриальную эпоху никуда. Это на хуторе можно обходиться личным умом.
Бухгалтерия есть ведение учет а по книгам (book keeping по аглицки). Сейчас вместо книг компы, но принципы те же
Сейчас вместо книг компы, но принципы те же
Не нужны те же самые принципы при совершенно других возможностях. В книге придумали промежуточный итог "сальдо", потому что сумму записей человеку долго считать, компьютеру это не нужно. В книге придумали специальные таблицы, чтобы человеку легче делать отчеты за период, компьютеру это не нужно. В книге сложно исправить запись, в компьютере наоборот.
Это устаревший подход, ориентированный на книгу, а не на компьютер.
Если бы это было так, никто бы не парился проблемами получения OLAP-кубов и вообще материализаций промежуточных вычислений
В книге сложно исправить запись, в компьютере наоборот.
Вот именно по этому и остаются бухгалтера, которые несут персональную ответственность за цифры в компьютере. Кстати в западных системах принципиально запрещено исправление записей. Можете исправить ошибку такой же отрицательной операцией (сторно). Но однажды внесенная операция остается свидетельством ошибки или попытки обмана.
Ответственность за достоверность данных в любом случае на человеке, который вносит эти данные в компьютер.
Ошибки и попытки обмана при изменении записей выявляются журналированием.
Я вообще о другом. Сторно, двойная запись, дебет с кредитом - эти бухгалтерские абстракции появились задолго до компьютеров, и утратили актуальность.
Вы ошибаетесь во ... всем :)
Начиная от "сальдо" которое человеку долго считать - компутеру тоже это долго считать и все базы хранят и пересчитывают это сальдо с каждой операцией. Обычно это называют типа materialized. В 1С это называют итогами. Но суть то не меняется это все то же самое сальдо.
Дебет с кредитом, ну опять же назовите это по другому, плюс/минус значение. Суть то от этого не поменяется.
Двойная запись - ну так это основа основ. Есть ваши деньги и есть ваши покупки. Не важно где это в базе данных, в двух микросервисах или любом другом месте. Факт в том что операция всегда должна одновременно и на одну и ту же сумму изменять их. Взять деньги с вашего счета и точно на эту же сумму положить в ваши покупки. Ни сотой копейки разницы быть не может. Хотите обзывайте транзакцией, хотите атомарной операцией, но вот бухгалтера это уже несколько столетий называют двойной записью.
Не изменилось абсолютно ничего. Только вот названия почему то стало сложно запоминать и осмыслять :)
Транзакция - это скорее проводка, если не путаю.
Двойная запись - своего рода избыточное кодирование, чтобы в какой-то момент сравнить две цифры, и проконтролировать целостность данных. Правда, мне непонятно, как она работает, если товар уже ушел, а деньги еще не отдали. Запишем в задолженность? Ну ок. А если товар сгорел вместе со складом, или отдан бесплатно на благотворительность? Тоже какие-то костыли?
С точки зрения бухгалтера, я конечно неправ, ведь я предлагаю сломать его теорию, проверенную столетиями на бумаге, теперь вот и в компьютер засунули. Но я смотрю с другого угла - как айтишник, который бухгалтерии никак не касался, имел опыт участия в написании систем по учету всякого, в том числе финансового. И волей случая пару раз просили как-то поправить что-то в 1С конфигурации, и было там всё так страшно и противоестественно, что вот видимо до сих пор травма осталась.
Двойная запись это обычная физика - закон сохранения энергии. Если в одном месте убыло то в другом обязательно должно прибыть. Ни больше ни меньше. Если деньги убыли/прибыли то эта же сумма обязана появиться/исчезнуть в другом месте. Деньги еще не отдали, но товар появился - значит на эту сумму обязана увеличиться задолженность перед поставщиками. Отдали на благотворительность - значит увеличиваются Прочие расходы. Вот и все, ничего сложного. Просто стандартизированные названия.
Кстати, в каких двух местах записать транзакцию "нам оплатили 1000 рублей за устную консультацию". +1000 наверное на счету или в долге нам. А -1000 где?
Вот это, как раз, просто.
Мы договариваемся о проведении консультации: +1000 "мы обещали" <=> -1000 "недополученная прибыль"
Проводим консультацию:
+1000 "нам должны" <=> -1000 "мы обещали"Получаем деньги:
+1000 "недополученная прибыль" <=> -1000 "нам должны"
Как только везде нули - операция считается завершенной.
Двойная запись - офигенная тема.
О как, получается, что по некому общему ИТОГО мы даже прибыль не видим.
Этот ИТОГО помогает только убедиться в правильности самого учёта.
Этот ИТОГО помогает только убедиться в правильности самого учёта.
Там, если я правильно понимаю, еще парочка параллельных транзакций забыта вида "Платежная система" -1000 -> "Наш текущий счет" +1000.
И все это как-то вместе увязано.
Проблема с таким подходом, что представлен, с моей точки зрения непонимающего - в том что нагло путают реальное хождение и учет денег и прочих обязательств и их классификацию "что это было и по какому поводу"
Вот это
Мы договариваемся о проведении консультации: +1000 "мы обещали" <=> -1000 "недополученная прибыль"
Не сходится по типам. Слева - обязательство, выраженное в деньгах. А правое - это, в общем, классификация этого обязательства.
Вот скажем, если это "мы обещали" хочется еще под метку "обязательства, выданные посредством сайта" подвести (ну вот хочется нам знать, сколько мы почтой, а сколько с сайта наобещали) - то придется что-то мудрить.
Конструкция, кстати, для меня выглядит совершенно синтетической. Чисто чтобы формулу баланса удовлетворить. Потому что обязательство "Мы обещали чего-то на 1000 рублей" именно из ниоткуда взялось.
Двойная запись - офигенная тема.
Для амбарной книги - да.
Для БД - зло, потому что перемешаны исходные данные и производные.
+1000 на счете или в кассе. -1000 во взаиморасчетак с клиентами. Когда вы эту услугу оказываете, у вас -1000 в Доходах, и +1000 во взаиморасчетах (взаиморасчеты "закрылись", вы никому ничего не должны). Начисляете зарплату -600 в расчетах с персоналом, +600 в доходах. Выплачиваете зарплату - +600 в расчетах с персоналом, -600 со счета или кассы (расчеты с персоналом "закрылись", вы работникам не должны). Начисляете налог на прибыль -100 по расчетам с бюджетом, +100 в доходах. Платите налог на прибыль -100 деньги, +100 расчеты с бюджетом (расчеты с бюджетом закрылись). Фонмируете финрез (закрываете месяц) - +300 доходы, -300 прибыль. Итого ваше предприятие имеет +300 в деньгах, и -300 на счету нераспределенной прибыли, т.е. 300 рублей активов (в нашем случае - денег), и 300 рублей пассивов (источников этих денег, в нашем случае - это нераспределенная прибыль).
"-" на счетах разных взаиморасчетов и прибыли - это "кредитовое сальдо", оно показывает тоже наличие средств на этих счетах, только они в данном случае являются "пассивом", "источником для активов", поэтому в данном примере отражаются с минусом. Если расписывать традиционно "по бухгалтерски", с дебетом-кредитом, будет немного сложнее для "не владеющих предметом". Поэтому я немного упростил. Но в принципе, ничего сложного нет - "для бухгалтерии хватает спинного мозга"©
Выплачиваете зарплату - +600 в расчетах с персоналом, -600 со счета или кассы (расчеты с персоналом "закрылись", вы работникам не должны).
Ага, ага. А почему не 100 штук (или сколько там работников)
-6 со счета или кассы <-> +6 банковский счет работника
Как я выше сказал - большая часть всех этих, якобы, перемещений средств и изменения обязательств - оно не столько про сколько у кого денег и сколько кому кто должен, а про "покраску" и навешивание категорий.
Работает, конечно, но местами коряво.
В примерах домашней бухгалтерии - вот как "по иерархическим счетам" нормально разбить четыре вида расходов (для учебы | для развлечения) * (подписка на сервис | покупка книг)
Ага, ага. А почему не 100 штук (или сколько там работников)
потому, что это был упрощенный пример, чтоб даже вам понятно было. Внутри счета, естественно, ведется аналитика по каждому объекту учета - и по контрагенту, и по работнику, и по виду налога, и по счету, и по кассе. И как раз "это всё" про то, кто и кому должен, и за счет чего есть деньги. И работает вполне нормально сотни лет.
В зарплате по работнику детализация на счете только на депоненте. А в банк или через кассу вся сумма уходит одной проводкой, плюс реестр или ведомость.
И работает вполне нормально сотни лет.
Работает, но не уверен что уж совсем удобно.
Прошу нормальный и логичный план счетов по примеру. (Чтобы все сразу и единообразно считалось непосредственно из полей двойной записи и плана счетов)
Нужно оформить в двойной записи покупки (из наличных денег)
Подписки на учебные сервисы
Подписки на развлекательные сервисы
Покупка учебников
Покупка художественной литературы
Это будет
1 Развлечения
1.1 Художественные книги
1.2 Развлекательные сервисы
2. Учеба
2.1 Учебники
2.2 Обучающие сервисыСумма на счете 1 - развлечение, на счете 2 - учеба. Хорошо. А где сумма "на книги"?
Или
1 Книги
1.1 Художественные книги
1.2 Учебники
2 Сервисы
2.1 Развлекательные сервисы
2.2 Обучающие сервисыТу, соответственно, вопрос наоборот.
Т.е. что так, что так мы вынуждены привлекать дополнительную информацию о том, что отдельные подсчета - это некая общая логическая сущность, по которой тоже хочется посчитать ИТОГО.
В каких разрезах вам надо учитывать, в таких и стройте учет. Если вы в ТЗ поставили учитывать по четырем - по ним и учитывайте. Если разбиваете четыре вида расходов на два направления - учеба и развлечения - то учитывайте по ним.
Я бы вообще предложил без разбивки на субсчета, единый счет "расходы на всякую хню" с двумя аналитиками - "направление" {"учеба", "развлечения"} и "предмет" {"сервисы", "книги"}
В каких разрезах вам надо учитывать, в таких и стройте учет.
Мне надо оба. И сколько на книги трачу и сколько на сервисы. Без привлечения дополнительного знания "это части одного целого". Пользуясь только тем, что учитывается в рамках двойной записи.
Странно, что коммент пропал.
я ж говорю, один счет, с двумя аналитиками. Купили учебник - кредит Карман, дебет Расходы на хню ("учеба", "книги"). И т.п.
Делаете отчет по первой аналитике - получаете, сколько на учебу потратили, а сколько на развлечения. Делаете по второй аналитике - сколько на бумагу, а сколько на электронку. Делаете фильтр по {учеба, книги} - получаете затрату на учебники. Делаете фильтр по {развлечения, сервисы} - получаете затраты на порнохаб.
я ж говорю, один счет, с двумя аналитиками
То что тут постоянно вспоминают про аналитики - разве не говорит, что инструментов и терминологии самой двойной записи -- недостаточно?
Потому что если использовать только ее терминологию - то использовались бы только названия счетов.
Но нет, надо дополнительные признаки вводить. Т.е. двойная запись сама по себе - неудобна и желаний пользователя не удовлетворяет.
А так, наиболее логичное с точки зрения происходящего - это счета 'Мой карман'(и прочие безналичные счета, что у меня есть) и по счету на каждого продавца, у кого я что-то покупаю. Так оно хоть реально движение средств показывает от кого к кому.
А все остальное - атрибутами/тегами, да. Только не на счет, а на каждую позицию покупки.
С документальным оформлением, опять же, так проще. Просканировал чек, взял выписку из банка - и готова запись в программе домашней бухгалтерии. "Я <-> Мерчант INN такой-то". А дальше классифицируй хоть вдоль хоть поперек, что ты там у него купил.
Бухучет (двойная запись) - это синтетический учет. Обобщенный по видам обязательств и имущества, причем выраженный только в деньгах в валюте учета. А уже по видам обязательств вы можете вести требуемый вам аналитический учет. Если он вам требуется. Но в итоге данные по аналитическому учету сводятся в одну сумму и отражаются в синтетическом учете.
Ну вот как пример - расчитываются с вами только золотом. Вы можете учитывать синтетически - остаток "5 кг золота, что составляет 100 таллеров", а можете добавить аналитику по видам - "1 кг золотым песком, 3 кг в драхмах, 1 кг в слитках, что состаляет всего 5 кг, т.е. 100 таллеров". А если вы работаете только с рублями, и валюта учета рубль - вам аналитика не нужна. Вы не можете разделить в кармане, а тем более на счете, рубли, пришедшие от Васи, зарплату и проценты банка по депозиту.
Т.е. двойная запись сама по себе - неудобна и желаний пользователя не удовлетворяет.
Двойная запись для того, чтобы "ничего не потерялось". Если у вас ушли деньги - значит, вам должны прийти какие-то другие активы. Если у вас внезапно появился какой-то актив - вы поймете, за счет чего он появился. Если активы и пассивы перестали соответствовать друг другу - значит, где-то вы ошиблись в подсчетах (потому, что при правильном отражении они не разойдутся)
То что тут постоянно вспоминают про аналитики - разве не говорит, что инструментов и терминологии самой двойной записи -- недостаточно?
Для чего именно недостаточно? Двойная запись -- это как контрольная сумма, ее задача -- контролировать, что операции записаны правильно и без ошибок. Для этого ее хватает. Двойная запись не предназначена для удобной аналитики, для этого есть другие инструменты
Потому что если использовать только ее терминологию - то использовались бы только названия счетов.
Теоретически можно использовать и названия счетов, но это неудобно и не позволяет отнести движение по счету на несколько разрезов.
А так, наиболее логичное с точки зрения происходящего - это счета 'Мой карман'(и прочие безналичные счета, что у меня есть) и по счету на каждого продавца, у кого я что-то покупаю. Так оно хоть реально движение средств показывает от кого к кому.
Ну так, теперь каждую операцию записывать как пару "списание с одного счета - поступление на другой счет", и получится двойная запись
А все остальное - атрибутами/тегами, да. Только не на счет, а на каждую позицию покупки.
Ну вы предлагаете то же самое, только название другое. В терминологии 1С -- это аналитический признак, по сути и есть атрибут или тег
С документальным оформлением, опять же, так проще. Просканировал чек, взял выписку из банка - и готова запись в программе домашней бухгалтерии. "Я <-> Мерчант INN такой-то". А дальше классифицируй хоть вдоль хоть поперек, что ты там у него купил.
Это абсолютно не противоречит двойной записи.
Суть двойной записи -- это контроль правильности. Вы рассуждаете на примере личных финансов, там необходимость двойной записи не очень видна и не совсем понятна, вы сами все вносите и сами все знаете.
Однако, если вы подумаете о большой организации, с сотней сотрудников, то поймете, что отловить ошибки в учете (как случайные -- забыли внести что-то в систему, неправильно ввели, так и намеренные -- украли где-то что-то) будет очень сложно.
Двойная запись частично решает этот момент, особенно, если нет сговора. Более того, она позволяет четко зафиксировать моменты передачи ответственности.
Скрытый текст
Набивший оскому пример с перевозкой денег из филиала в одном городе в филиал в другом:
Бухгалтерия филиала А выдала 1000 долларов, получила от него расписку, занесла в учетную систему две транзакции: списание со счета "Наличные деньги #филиалА" и зачисление на "счет" "Деньги в пути #экспедиторПетров". Ответственность за сохранность денег теперь лежит на Петрове
Петров приехал в филиал Б и сдал в кассу 900 долларов. Бухгалтерия в филиале Б записала опять же две транзакции: списание со счета "Денги в пути #экспедиторПетров" и зачисление на счет "Наличные деньги #филиалБ". Ответственность за 900 долларов теперь на филиале Б.
Уже в этот момент мы видим, что сумма всех транзакций не равна нулю. Т.е. что-то не так. Путем нехитрого (но потенциально долгого и кропотливого) анализа мы видим, что Петров присвоил сотку.
Без двойной записи этот момент мог легко потеряться: когда на предприятии сотни людей и десятки тысяч транзакций в сутки, уследить за всем невозможно. Перепроверять каждую операцию вручную (звонком в филиал и выяснением, сколько же денег должен был привезти Петров) очень трудоемко. Операции могут быть растянуты по времени, разбиты на несколько операций, и т.п.
Для чего именно недостаточно? Двойная запись -- это как контрольная сумма, ее задача -- контролировать, что операции записаны правильно и без ошибок.
Пока ручками в амбарные книги писали - да. Но сейчас то или программа одно и то же число в две таблицы пишет, или пользователь через copy/paste. Ну и толку?
Ну и толку?
Даже если сделан правильный copy/paste надо еще проверять, что он сделан в нужное место. Вот и проверяют.
Для того, чтобы двойная запись начала работать, надо не две транзакции, а как минимум четыре. Причем, желательно, сделанные разными людьми в разных местах.
Посмотрите под катом пример с перевозкой денег. Никакую из четырех транзакций (выдача денег с филиала А - получение денег экспедитором - передача денег экспедитором - получение денег филиалом Б) нельзя убрать или заменить "одним числом". Да, каждая пара формируется автоматически, и автоматически (в случае учетной системы) в паре будет одинаковая сумма. Но суть именно в том, что каждая физическая хозяйственная операция будет записана как набор таких пар, возможно разными людьми и в разное время. И если что-то записано неправильно, то "баланс не сойдется", и будет видна ошибка.
Для чего именно недостаточно?
Для выяснения всего, что хочется узнать и хранения данных, из которых мы это узнавать будем.
Теоретически можно использовать и названия счетов, но это неудобно и не позволяет отнести движение по счету на несколько разрезов.
Про это я и сказал тут - что сама по себе, без навешивания в разные места дополнительных данных (аналитических признаков) она не так уж и удобна.
Вы рассуждаете на примере личных финансов,
Это потому что популярные статьи (англоязычные обычно) - они на примере личных финансов. И чтобы хоть как-то увести обсуждение с обсуждения учета в организации к обсуждению самого принципа учета. Не очень успешно получается, да.
Набивший оскому пример с перевозкой денег из филиала в одном городе в филиал в другом:
Тут было лучше :-)
Не субсчета, а аналитики. В этом примере - центры затрат.
Очередной воинствующий дилетант, которому пора бы понять, что решения "а давайте вашу устаревшую херню заменим на новую" в подавляющем большинстве случаев так просто не работают.
Про двойную запись (и как ее реализовать в реляционной БД) у меня есть перевод хорошей статьи. Которая помогла мне разобраться в этой теме, когда мы для нигерийцев делали ядро платежной системы.
Спасибо, интересная статья, и комментарии там. Вот этот ближе всего к тому, что я хотел сформулировать, и я пока остаюсь при этом мнении.
Не в той плоскости думаешь.
Ты не меняешь деньги на товар ты переводишь деньги с одного счета на другой, и за это тебе отдают товар.
Чтобы деньги с одного счета попали на другой тебе нужно 2 полупроводки, одна чтобы деньги снять, другая чтобы деньги положить.
Дальше как в БД, тебе нужно убедиться что у тебя сняли у них добавили, для этого и подводят дебиты/кредиты, но это происходит не только у тебя в бд, это происходит у тебя, у РосБанка, у продавца, к ним добавляются еще по банку с каждой стороны.
то есть денюжка идет:
Твой счет-счет банка-счет РосБанка-счет банка продавца-счет продавца.
И вот когда у кого-то из этой 5ки циферки не сойдутся тебе и понадобиться вся эта куча информации про транзакции.
Все это пробовали упростить в СБП - но там объем информации и отчетности по ней, на мой взгляд, только вырос.
Не надо усложнять сверх необходимого. Какое дело вам (конторе), как этот перевод отражается в банке?
Ну и СБП - это тоже не так уж и сложно
Ну так бухгалтерия ведется не для начальника, а для налоговой. А налоговой очень интересно как все это бьется с банками.
СБП - я привел для примера того, что вся эта махина не стоит на месте а хоть немного-но шевелится. Ну да, там не сложно 16 документов по 250 листов, с описаниями процессов. Но если прям выжимкой, то в сумме будет страниц 200, если без таблиц с описанием файлов.
Банки врут, но это еще пол беды. Беда что банки отчаяно врут.
На ретейле с потоком покупателей в десятки тысяч в сутки приходится поддержке разбирать цепочки платежей/частичных платежей/возвратов в разных платежных системах, бонусов, хуенусов и т.п. которые не соответствуют их ожиданиям в большинстве своем в пользу банка. Клиенту до внутренностей пофиг, у него принцип одного окна: стойка обслуживания клиентов вашего ретейла. Банки дают отчетность по прошедшим транзакциям и там мрак я даже не представляю у них там обфускация данных что ли что бы никто не догадался или такие задержки транзакций по времени в несколько суток. Цепочку переводов в разрезе всех связанных транзакций приходится расшивать прям на стойки клиентов.
Второй момент импорт, это тот, который "не пересекается" в геометрическом смысле. Оплаты по этому импорту такие же "не пересекающиеся" и не приход денег до конечного поставщика это не его проблемы, а Ваши и платеж разбит на много "непересекающихся" транзакций и деньги с Вашего счета ушли, но до поставщика не дошли или не все дошли и он нервничает и Вы нервничаете.
Звучит стремно. Я даю команду банку перевести с моего счета (в этом банке) деньги продавцу неважно где, банк принятие команды подтвердил, почему я дальше должен отслеживать эту цепочку кто какой передаст? Если операция перевода денег конечному получателю асинхронная, пусть банк этим и занимается, иначе зачем он вообще нужен? Может тогда и правда лучше блокчейн?
Если операция перевода денег конечному получателю асинхронная, пусть банк этим и занимается
Судя по всему когда-то давно так и было. Отдал бумагу в свое отделение, отдал другую бумагу купцу как доказательство, что перевел. А дальше купец уже у себя в стране деньги получает, доверяя банку в том, что в лепешку расшибется, но деньги довезет.
Но потом банки решили уменьшить риски, набрать побольше клиентов, ну и получили что получили.
Это печально в цифровую эпоху, когда в любом мессенджере есть галочка подтверждения получения.
Это печально в цифровую эпоху, когда в любом мессенджере есть галочка подтверждения получения.
На эту тему я много спорил в похожих темах, выясняя, почему подтверждения о получении платежки от банка получателя недостаточно, чтобы считать, что платеж (с точки зрения того, кто платит и того, кому платят) - совершен.
А мне долго объясняли, что вот эти все мгновенные платежи - это что банки лишь старательно притворяются, пытаясь не грузить лишней информацией. Но если поскрести - то сразу выяснится, что нет, ничего подобного, вы, граждане, ошибаетесь.
Ну вот потому что банки и банковская/платежные системы сами себе не доверяют.
Судебная практика говорит именно о том, что моментом исполнения обязательства в виде оплаты считается подача в банк платежного расходного поручения, при условии, что получатель верный, а поручение было принято к исполнению. В момент принятия к исполнению банк начинает нести ответственность в том числе за убытки, которые могут быть причинены задержкой исполнения или неисполнением, либо исполнением в адрес ненадлежащего получателя. В момент перечисления банком плательщика ДС в адрес банка получателя происходит переход этой ответственности к банку получателя.
В роли платежного получения, кстати, может выступать исполнительный лист.
Те же соображения работают, например, при определении момента совершения юридически значимых действий в виде направления корреспонденции почтой: моментом отправки, например, для применения сроков давности, считается момент передачи письма Почте России, а не момент получения или хотя бы прибытия в отделение получателя.
Судебная практика говорит именно о том, что моментом исполнения обязательства в виде оплаты считается подача в банк платежного расходного поручения, при условии, что получатель верный, а поручение было принято к исполнению.
Мооожет быть. Но почему-то, если порыться, в записях о покупке в банк-клиенте для каких то целей часики показывают "не, не, платежа на самом деле еще нет, ждите".
Если бы это не имело значения для меня, как покупателя - это бы не показывалось. Это не может быть 'моментом исполнения' хотя бы по той причине, что платеж могут завернуть по дороге по каким-то причинам.
Судебная практика говорит именно о том, что моментом исполнения обязательства в виде оплаты считается подача в банк платежного расходного поручения
"Если договором не установлено иное", как всегда. И если кому-то очень очень надо, а поставщик не хочет работать без денег, или если просто не вчитываясь подписал договор - то будет момент поступления.
Кроме того, есть еще вариант "деньги ушли, но потом в какой-то момент развернулись и вернулись к обратно на счёт к плательщику".
И если в этом случае плательщик будет настаивать на исполнении обязательства "потому что он оплатил", а на самом деле в итоге деньги к нему же и вернулись - ну он будет как минимум недобросовестным, а то и злоупотребителем правом.
Судебная практика говорит именно о том, что моментом исполнения обязательства в виде оплаты считается подача в банк платежного расходного поручения
А как же ГК РФ Статья 316? "в месте нахождения банка (его филиала, подразделения), обслуживающего кредитора, если иное не предусмотрено законом"
То есть, ГК РФ говорит, что моментом исполнения денежного обязательства является зачисление денежных средств на корреспондентский счет банка, обслуживающего кредитора, либо банка, который является кредитором.
Там конечно тоже с предварительной оговоркой про то, что если иное не определено "... иными правовыми актами или договором, не явствует из обычаев либо существа обязательства" (аж обычаи делового оборота явно указали, хех), но вы верно заметили...
Правда, вы с santjagocorkez говорите о разном - вы о месте исполнения обязательства, а он - о времени его исполнения.
На практике вполне нормально, что моментом исполнения обязательства будет момент отправки денег, но если они не придут - оно не будет исполнено несмотря на то, что деньги были отправлены. Вплоть до того, что в договорах часто явно указывают, какой из двух моментов времени считать моментом исполнения плательщиком обязательства по оплате.
говорите о разном - вы о месте исполнения обязательства, а он - о времени его исполнения.
Есть постановление Пленума Верховного Суда РФ от 22.11.2016 N 54, где сказано: "По смыслу пункта 1 статьи 316 ГК РФ, если иное не предусмотрено законом, по денежным обязательствам, исполняемым путем безналичных расчетов, местом исполнения обязательства является место нахождения банка (его филиала, подразделения), обслуживающего кредитора (получателя средств). При этом моментом исполнения денежного обязательства является зачисление денежных средств на корреспондентский счет банка, обслуживающего кредитора, либо банка, который является кредитором."
То есть, с точки зрения ВС РФ, место так же определяет и момент.
Можете проверить на практике, оплачивая налоги в последний день во второй половине дня. С большой вероятностью получите начисленную пеню и опротестовать в суде это не сможете.
То есть, с точки зрения ВС РФ, место так же определяет и момент.
Тут, правда, есть пара нюансов -
во-первых, на корсчёт банка кредитора, а не на расчётный счёт кредитора (в законе это чётко не определено, к сожалению, так что урегулировать договором не помешает...)
во-вторых, если кредитор сменил банк и не сообщил об этом, то обязательство могут посчитать исполненным несмотря на возврат денег...
и дополнительно есть еще более интересный нюанс как раз по теме - что получателю банк может сообщить о поступлении средств до того, как они фактически поступят. Например, при оплате картой - "платёж прошел", а деньги реально еще в пути, может даже несколько дней.
в законе это чётко не определено
Не понял. В ГК РФ это определено как раз однозначно.
если кредитор сменил банк и не сообщил об этом, то обязательство могут посчитать исполненным несмотря на возврат денег
Впервые о таком слышу. Пруф?
при оплате картой - "платёж прошел", а деньги реально еще в пути, может даже несколько дней
Опять жду пруфов, когда при завершенной транзакции оплаты картой платеж не дошел до корреспондентского счета банка. То, что договор эквайринга почти всегда подразумевает зачисление денежных средств на расчетный счет торгового предприятия на следующий рабочий день - это понятно. Банк так минимизирует свои издержки, сокращая количество операций по счетам. Но как может быть "платеж прошел" до зачисления денежных средств на корреспондентский счет банка в процессинговом центре - я не понимаю.
Но как может быть "платеж прошел" до зачисления денежных средств на корреспондентский счет банка в процессинговом центре - я не понимаю.
Чек у продавца печатается? Значит - прошел. Ибо с точки зрения налоговой он эти деньги получил.
Чек не будет распечатан до завершения транзакции. А транзакция считается завершенной зачислением денежных средств на корреспондентский счет банка эквайра в процессинговом центре.
Чек не будет распечатан до завершения транзакции.
Вот постоянно - чек(кассовый) есть, а часики в банк-клиенте еще висят. Очевидно, показывая, что транзакция (в каком-то ее смысле) еще не завершена - чтобы я это знал. И оно, видимо, так и есть - потому что если там по дороге сломается и деньги вернутся, то мерчант попросит же деньги снова (хз как это чеками оформляется и что потом про них налоговая думает).
А ведь еще offline решим покупки карточками бывает, где чек уже есть, а деньги вообще никуда не сдвинулись (у нас так, скажем, продажа билетов в общественном транспорте работает). В отличии от взаимных обязательств, которые не совсем деньги.
Оно все несколько логичнее, в старой, офллайновой терминологии - когда у продавца чек (уже не кассовый) есть, и он делает pull средств через свой банк и банковскую систему.
А сейчас - всю терминологию и отображение происходящего смешали и запутали.
транзакция (в каком-то ее смысле) еще не завершена
Она завершена списанием денежных средств с корреспондентского счета банка эмитента и зачислением их на корреспондентский счет банка эквайра. Списание или зачисление денежных средств банк может производить с задержкой на несколько дней, что ни как не влияет на факт завершения транзакции.
А ведь еще offline решим покупки карточками бывает, где чек уже есть
Это уже продажа в кредит за счет торговой точки. Но с таким уже лет 20 не сталкивался.
у нас так, скажем, продажа билетов в общественном транспорте работает
В какой стране так до сих пор рискуют, экономя на GSM модуле?
Она завершена
Если бы она была завершена ("все, можно об этом больше не думать")- мне бы часики не показывали за ненадобностью.
Именно этого же хотели в начале этой ветки: "Я даю команду банку перевести с моего счета (в этом банке) деньги продавцу неважно где, банк принятие команды подтвердил, почему я дальше должен отслеживать эту цепочку кто какой передаст?"
В какой стране так до сих пор рискуют, экономя на GSM модуле?
В России.
Никаких проблем. Мелкая покупка. десятки рублей На груди кондуктора - кассовая машинка. Она все продажи запоминает и только на конечной остановке, судя по всему, запускает сам процесс. Там даже QR кодов от оператора фискальных данных нет - видимо, исключение где-то в законе есть.
Если денег вдруг на счету не нашлось - карта улетает в бан-лист до момента, пока долг не погасится.
В России.
Где точно? Пруф? Ни разу такого не встречал.
На груди кондуктора - кассовая машинка
Непонятен смысл экономии на GSM модуле. Он же копейки сейчас стоит. По сравнению с ценой мобильной ККМ - пару процентов.
Вы не путаете банковские карты с предоплаченными смарт-картами транспортной компании?
Если денег вдруг на счету не нашлось - карта улетает в бан-лист до момента, пока долг не погасится.
Дебетовые карты сейчас можно бесплатно хоть каждый день оформлять. К тому же память для бан-листа в ККМ будет стоить в разы дороже GSM модуля. У меня одного старых закрытых карт больше десятка наберется.
QR кодов от оператора фискальных данных нет
QR коды используются для СБП
Где точно? Пруф? Ни разу такого не встречал.
Ижевск: "Обратите внимание, что списание денежных средств с Вашего банковского счёта осуществляется не в момент прикладывания карты к терминалу кондуктора и получения билета, а только после передачи данных и обработки платежа банком."
Непонятен смысл экономии на GSM модуле. Он же копейки сейчас стоит. По сравнению с ценой мобильной ККМ - пару процентов.
Систему ввели давно. Возможно, решили машинки не менять.
Вы не путаете банковские карты с предоплаченными смарт-картами транспортной компании?
Нет, не путаю. Обычные NFC банковские карты читают. В смысле начиналось оно с картами с транспортным приложением и, вроде, оно так даже все еще работает. Но вряд ли кто пользуется. Это просто неудобно.
QR коды используются для СБП
Не те QR. А те, которые для ОФД и закона 54-ФЗ. Которые еще каждый желающий может проверить. Или даже так - приложением от налоговой службы.
"Обратите внимание, что списание денежных средств с Вашего банковского счёта осуществляется не в момент прикладывания карты к терминалу кондуктора и получения билета, а только после передачи данных и обработки платежа банком."
Так это всегда так. И я об этом писал. "Списание или зачисление денежных средств банк может производить с задержкой на несколько дней, что ни как не влияет на факт завершения транзакции."
Но вряд ли кто пользуется. Это просто неудобно.
В Москве стоимость проезда через Тройку, включая виртуальную на смартфоне или банковской карте, просто на ~10% дешевле, чем при оплате картой. Поэтому желающих переплачивать не так много.
которые для ОФД и закона 54-ФЗ
Там куча исключений в статье 2.
Списание или зачисление денежных средств банк может производить с задержкой на несколько дней, что ни как не влияет на факт завершения транзакции."
Вопрос в том - зачем мне эти часики в банк-клиенте показывают, если 'не влияет'? Завершилась транзакция - ну и завершилась. Но ведь нет. Очевидно, есть случаи, когда 'есть нюанс' и выяснится, что нет, ничего подобного.
Я уже отвечал на этот вопрос. "Банк так минимизирует свои издержки, сокращая количество операций по счетам"
Где точно? Пруф? Ни разу такого не встречал.
Да везде, inkelyad всё правильно сказал. Межбанковские платежи идут через Банк России (а у международных цепочка будет длиннее). Если идёт через т.н.з. "сервис несрочного перевода", с 2018г фактически заменившего банковские рейсы, то там переводы обрабатываются каждые 30 минут, если правильно помню. По СБП - 15 секунд, тоже если правильно помню.
В любом случае за то короткое время, которое проходит приложение карты к ридеру и до вывода сообщение "оплата прошла" - деньги не успеют уйти от банка в банк через Банк России, даже за 15 секунд СБП, не говоря уж о получасе - и при этом Банк России еще и задержать платёж может.
Да везде
Похоже Вы русский язык не знаете. Попробую написать по английски: Provide proof by citing an authoritative source.
Похоже
Вообще это сравнительно общеизвестный факт, но со ссылкой на нормативку, а не "оно так по факту работает" лучше кого-то из банковской сферы попросить объяснить. Остальным достаточно просто знать, что сообщение "платёж прошел" - еще не означает, что прошел межбанковский перевод.
Да, всё верно, банк снижает свои издержки таким образом, не спорю, но тем не менее...
Вообще это уже объяснялось даже на Хабре - https://habr.com/ru/articles/469635/ , там так и пояснялось - " Когда вы увидели надпись об успешном переводе (и у вас деньги списались, а получателю начислились), на самом деле деньги еще никуда не ушли, успешно прошла только авторизация. Деньги уйдут на следующий день, после того как в конце операционного дня ПС проведет клиринг и сообщит банку-эмитенту карты отправителя, что ему необходимо отправить деньги в банк-эмитент карты получателя, а также выставит отдельный счет для оплаты комиссии в пользу ПС. Именно поэтому иногда переводы задерживаются, так как некоторые банки ждут завершения фактических расчетов, которые происходят только на следующий день."
Она все продажи запоминает и только на конечной остановке, судя по всему, запускает сам процесс.
Да даже если онлайн через GSM модуль передала - платёж от банка в банк напрямую не пойдёт же, а через Банк России.
А там поллитру курить надо, чтобы всё в деталях понять https://www.consultant.ru/document/cons_doc_LAW_367694/
Не понял. В ГК РФ это определено как раз однозначно.
В ст.316 ГК РФ сказано "в месте нахождения банка (его филиала, подразделения), обслуживающего кредитора". Тип счёта - корреспондентский счёт банка или расчётный счёт получателя в банке - не сказано. А постановление Пленума ВС - это не закон, формально говоря. Но очень интересный источник права - формально суд не наделён функцией нормотворчества, но фактически...
Впервые о таком слышу. Пруф?
Судебная практика потому что.
Основывается на недобросовестности кредитора - реквизиты в договоре указаны, если он не сообщил об их изменении - то сам и виноват, что деньги не получил. Когда будет прецедент (при том, что право, формально, не прецедентное) от ВС - будет яснее, как разруливать такую ситуацию.
Опять жду пруфов, когда при завершенной транзакции оплаты картой платеж не дошел до корреспондентского счета банка.
Практически любой платёж по карте. В отличии от платежа по реквизитам счёта, он работает по-другому: деньги блокируются в банке плательщика, получателю приходит уведомление, а фактически деньги от банка в банк идут как обычно, по-моему каждые полчаса идут оплаты между банками, если ничего не поменялось, но может и до законных 5 дней быть.
Тип счёта - корреспондентский счёт банка или расчётный счёт получателя в банке - не сказано.
Но так как зачисление на расчетный счет невозможно без предварительного зачисления на корреспондентский счет, интерпретировать это по другому не получается. Что и указал ВС РФ,
Судебная практика потому что.
Вы издеваетесь? Пруф где? Или Вас на ГИС Правосудие забанили?
Практически любой платёж по карте.
Опять не вижу ссылок.
Но так как зачисление на расчетный счет невозможно без предварительного зачисления на корреспондентский счет, интерпретировать это по другому не получается. Что и указал ВС РФ,
Но поскольку зачисление на расчётный счёт может произойти позже зачисления на корреспондентский счёт - иногда уже с другой датой - то в договоре можно и явно определиться "во избежание". О чём тут и речь.
Вы издеваетесь? Пруф где? Или Вас на ГИС Правосудие забанили?
Нет, но обзоры практики из Гаранта публично не доступны, а специально искать отдельные решения в ситуации, когда право не прецедентное и потому отдельное решение само по себе ничего не значит (если это не решение ВС) - бессмысленно. Так же как делать вывод о законности или незаконности этого решения на основании судебной практики, не прошедшей проверку в ВС. Но и не учитывать практику - тоже нельзя.
А повторять работу специалистов того же Гаранта или Консультанта по обзору практики - тоже бессмысленно.
Так что если реально надо, а не просто пруф ради пруфа - то когда буду за стационарным компом, смогу выгрузить оттуда справку.
Опять не вижу ссылок.
Под другим комментарием. Опять же, если не доверяете тому или подобному ему объяснениям - лучше спросить "банкира", он быстрее объяснит, чем даже вместе с вами будем курить тот же закон об НСПК и регламенты Банка России...
в договоре можно
При чем тут договор, условия которого, в общем случае неизвестны? Речь именно о то, как это регулируется законодательно.
обзоры практики из Гаранта
Вы читать умеете? Точно? Зачем мне обзоры, если я просил ссылку на ГAС Правосудие, которая общедоступна?
Под другим комментарием.
Простите, мне надоело. Демагог на то и демагог, что пруфы приводить не может и ищет тысячи отмазок.
Зачем мне обзоры, если я просил ссылку на ГAС Правосудие, которая общедоступна?
Ну потому искать в ГАС Правосудие то, что другие и так за нас нашли, - пустая трата времени, в том числе и потому, что можно пропустить какую-то важную деталь.
Я вот запомнил про возврат средств, но упустил из виду последующее действие по ст.371 ГК РФ:
"Возврат банком должнику денежных средств по причине закрытия расчетного счета кредитора считается достаточным доказательством уклонения кредитора от получения исполнения, дающим должнику право внести деньги в депозит нотариуса
"
Закрытие счета кредитора в банке не лишает должника возможности надлежащим образом исполнить обязательство по договору путем внесения денег в депозит нотариуса
Простите, мне надоело.
То есть объяснения типа такого https://habr.com/ru/articles/469635/ вам мало, вам надо, чтобы то же самое в разъяснении сказал банк?
Ну ладно: https://www.gazprombank.ru/pro-finance/perevody/skolko-idet-bankovskiy-perevod/
Когда вы переводите деньги на карту, создается иллюзия мгновенного перечисления. На самом деле средства проходят те же этапы, что и при переводе на расчетный счет. Банки часто предоставляют возможность использовать деньги до их фактического зачисления на счет, что дает эффект моментального перевода.
...
Финансовые учреждения, как правило, проводят обработку транзакций с получасовыми интервалами на протяжении рабочего дня. Под рабочим днем подразумевается период, когда банк активно выполняет операции по счетам своих клиентов. Важно учитывать, что главный регулятор банковской системы России функционирует в будни, с часа ночи до восьми вечера по столичному времени, что сказывается на темпах проведения межбанковских операций.
Переводы эти в месенджера не зарегулированы так сильно регуляторами.
Ваша цепочка переводов это распределенная транзакция по участникам/времени/регуляторам и юрисдикциям и прерывание транзакции там может случиться в любой момент. И если Вы думаете что нормативная база регуляторов продумана, логична и непротиворечива и технически доведена до совершенства и бесшовно синхронизирована между собой - то Вы зря так думаете.
Второй вопрос что есть банки, где допустим с технической частью все более менее предсказуемо, но их работа построена на исключении всего, что может вызвать сложность, в них у Вас еще и деньги не возьмут потому что Вы под эти свойства не подпадаете.
А там, куда Вы в итоге придете - так задайте вопрос почему я оказался в этом щитбанке, который не гарантирует транзакций?
Нет там никаких чудес, банки на этой же грешной земле что и мы с вами работают с самой грешной сущностью. Было бы странно если бы было по другому.
Банки, собственно, этим и занимаются. Последние разборки с банками на тему "где застряли деньги" я помню только в 1996-м.
Браво
А потом у тебя в zupa-dupa-zikwel бухгалтерии бухгалтер поменяет документ задним числом (и неважно, как именно: прямой правкой или добавлением документа-корректировки). И по промежуточным итогам у тебя выйдет, что ты отгрузил ТМЦ, которые ещё не произвел (или не привез поставщик). Но это половина беды, если по итогу отчетного периода сумма сойдется, хоть и неприятно. Самое главное, что между отменой первичного документа и коммитом корректировки «высвободившиеся» ресурсы может «обнаружить» склад / отдел продаж, и отгрузить их ещё раз. Вот тогда можно взлетать к центру галактики без всяких спейсшипов.
В учете не надо быстро менять записи. Идея как в том, чтобы просто поменять был нельзя. Учите бух учет там много полезного :)
Ну да, а потом для расчета деятельности за месяц какого нибудь газпрома в стране надо возводить новый суперкомпьютер невиданной мощьности.
Проводки туда-сюда? Это так называемый принцип двойной записи: откуда ушло и куда пришло. Изобретен пять веков назад в эпоху Возрождения. Опубликован Лукой Пачиоли. Иллюстрировать помогал сам Леонардо (по памяти привожу, может Леонардо и ни причем: проверьте в Вике). Без двойной записи получится как энергия ниоткуда.
У меня это объяснение давно сомнение вызывает. Мне почему то кажется, что вначале он было, по сути, протоколом транзакции.
Т.е. сначала вносится одна сторона записи "деньги перевели на счет XYZ в филиале ABCD". И только потом, когда пришло подтверждение, что деньги довезли - делалась вторая половина. (В филиале, соответственно, наоборот - сначала запись "нам деньги отправили, потом запись "мы деньги получили")
Или сначала запись "выдали деньги на покупку...", потом вторая половина "ага, вот и подтверждение о том, что реально купили".
Именно в таком формате оно позволяет проверять на ошибки. "Суммы справа и слева не сходятся - значит, деньги отправили, но куда-то делись или еще не доехали".
А в том виде как сейчас объясняют, когда обе половики делают одновременно и суммы "справа" и "слева" сходятся автоматом - непонятно, какую именно ошибку и как оно ловит.
сначала вносится одна сторона записи "деньги перевели на счет XYZ в филиале ABCD". И только потом, когда пришло подтверждение, что деньги довезли - делалась вторая половина.
У Вас получается, что сальдо счета ДС уменьшилось, а никаких других счетов - не увеличилось. Нарушилось правило нулевой суммы по всем счетам баланса. Деньги ушли, а где они - неизвестно.
В это случае должен быть сначала Кт 50.1 - Дт 57. А когда довезли, то Кт 57 - Дт 50.2
Или сначала запись "выдали деньги на покупку...", потом вторая половина "ага, вот и подтверждение о том, что реально купили".
Кому выдали? Кто за них отвечает? Если же двойной записью, то Кт 50 - Дт 72. И конкретный сотрудник должен за этот 72 счет отчитаться авансовым отчетом. И если сотруднику выдали 100 рублей на канцтовары, а он купил ручку за 80 рублей, то он должен 20 рублей вернуть (Дт 50 - Кт 72), а за ручку отчитаться чеком на 80 рублей (Дт 44 - Кт 72). И больше он ничего не будет должен.
Именно в таком формате оно позволяет проверять на ошибки. "Суммы справа и слева не сходятся - значит, деньги отправили, но куда-то делись или еще не доехали".
Во-первых, тогда в произвольный момент времени они вообще никогда не будут сходится. Во-вторых, будет именно "куда-то делись", а не находятся на конкретном счете с конкретными аналитиками, известно для чего и кто за это отвечает.
У Вас получается, что сальдо счета ДС уменьшилось, а никаких других счетов - не увеличилось. Нарушилось правило нулевой суммы по всем счетам баланса. Деньги ушли, а где они - неизвестно.
Именно. То что суммы расходятся - именно это и показывает, что деньги неизвестно где. Тот, кто отправил деньги, именно это и хочет знать. Для чего сравнивает "ушли"(от меня) и "пришли"(к ним).
В это случае должен быть сначала Кт 50.1 - Дт 57. А когда довезли, то Кт 57 - Дт 50.2
Это сейчас. Я про происхождение записи, что она на тот момент означала и как понималась. Когда до придумывания всей этой нумерации еще долго было.
Во-вторых, будет именно "куда-то делись", а не находятся на конкретном счете с конкретными аналитиками, известно для чего и кто за это отвечает.
Они не находятся... или не совсем находятся их еще не довезли. И филиал, если там эти деньги со счета попросят - мог и просто физически их не выдать ввиду отсутствия в сейфе нужной суммы.
Отголоски всего этого мы до сих пор наблюдаем, когда видим, что деньги несколько дней идут, хотя вроде транзакция покупки 'совершилась'.
это и показывает, что деньги неизвестно где
Вот и я про это. Неизвестно где, вместо того, что точно известно где и кто за них несет ответственность.
Это сейчас.
Какая разница? Просто номер счета писать быстрее, чем словесное его описание. Никто не запрещает использовать другую нумерацию счетов для небюджетных предприятий. С бюджетными предприятиями и бюджетным планом счетов - отдельная тема.
Вот и я про это. Неизвестно где, вместо того, что точно известно где и кто за них несет ответственность.
Да про историю же речь, а не про то как оно сейчас это должно работать и для чего используется. Когда вот реально деньги неизвестно где. Караван ушел и находится черти где. Кто ответственен - написано в 'левой' части записи "Отправили 100 золотых туда-то (сноска - караваном господина такого-то)"
Я про то, что у меня есть сильные подозрения (и в чем меня еще не разубедили), что когда оно придумывалось - все воспринималось совсем не так, как сейчас описывается.
Возможно, это воспринималось не так даже совсем недавно. А именно в доэлектронную эпоху.
Вроде:
Поступил документ о переводе. Мы написали(в бумажную карточку счета) одну сторону проводки, отправили бумагу на другой этаж, где счетом получателя занимаются и только когда они подтвердили - написали другую сторону. Т.е. в некоторый момент суммы реально не сбалансированы. И по этим расхождениям можно искать, где с операциями накосячили. А не как сейчас - "такого не может быть".
Вот есть в Google Books сканы книг века 17-18. В том числе по банковскому/бухгалтерскому делу. В какой из них можно прочитать, как у них там все реально работало?
Кто ответственен - написано в 'левой' части записи "Отправили 100 золотых туда-то (сноска - караваном господина такого-то)"
Так эта "сноска" и есть корреспондирующий счет, который обязан всегда присутствовать.
Возможно, это воспринималось не так даже совсем недавно.
Точно так же. Каждая хозяйственная операция должна быть отражена непременно дважды: по дебету одного счёта и по кредиту корреспондирующего с ним счёта.
Мы написали(в бумажную карточку счета) одну сторону проводки, отправили бумагу на другой этаж, где счетом получателя занимаются и только когда они подтвердили - написали другую сторону.
Тут нет двойной записи. Потому что "отправили бумагу" и "получили" - разные хозяйственные операции в разных местах и в разное время. А каждая хозяйственная операция - это транзакция.
Так эта "сноска" и есть корреспондирующий счет, который обязан всегда присутствовать.
Как-то я не уверен в такой интерпретации. Наверняка догадались, что это тоже счет, который можно записывать с другой стороны проводки - несколько позднее. (Или это с нашей точки зрения такая сноска это - коррсчет, а вот с точки зрения пользователя тогда - точно ли так же считали? Там, вообще, понятие 'корреспондирующий счет' было придумано?)
Иначе можно договориться до того, что вообще любой способ записи денежных операций, где мы записываем "от кого к кому деньги(физические монеты) передали" - это двойная запись. Что, вроде бы, не так.
В общем, нужна большая толстая книга по истории бухгалтерского учета и банковского дела.
несколько позднее
То есть сначала отдадите деньги, а "несколько позднее", если вспомните, запишете кому их отдали? )))
Иначе можно договориться до того, что вообще любой способ записи денежных операций, где мы записываем "от кого к кому деньги(физические монеты) передали" - это двойная запись. Что, вроде бы, не так.
Как раз по правилам бухгалтерского учета - только так. Если мы даем кому-то аванс, то мы должны не только отразить, что у нас стало меньше денег (кредит счета денежных средств), но и то, кому и за что этот аванс дали (дебет счета авансов выданных).
То есть сначала отдадите деньги, а "несколько позднее", если вспомните, запишете кому их отдали? )))
А вот не надо путать и накладывать современную интерпретацию. В примере записали сразу. Но в отдельное понятие 'счет' не выделили. Счет - это карточка/номер клиента в филиале. А что караванщик нам должен - ну сноска есть. Если запись останется несбалансированной через <срок> (правая половина с подтверждением не появилась) - пойдем искать, куда подевался.
Счет - это карточка/номер клиента в филиале.
У головного предприятия свой баланс и свой бухгалтерский учет, а у филиала - свой. А то что, он при закрытии периода участвует в консолидации - это уже совсем другая тема.
А карточка/номер клиента - это уже аналитика счета.
сноска есть
Я уже писал Вам, что "сноска" и есть корреспондирующий счет, который обязан всегда присутствовать.
Если запись останется несбалансированной
Но так как операции отражаются постоянно, то, в общем случае, баланса у Вас вообще никогда не будет.
Но так как операции отражаются постоянно, то, в общем случае, баланса у Вас вообще никогда не будет.
То что прямо сейчас - никогда не сойдется, да.
А условный "за прошлый год/месяц", где когда все операции должны уже завершиться - можно и посчитать. И если что-то не сошлось - начать искать, где ошиблись.
А условный "за прошлый год/месяц", где когда все операции должны уже завершиться - можно и посчитать.
Так в общем случае момента, когда все операции завершатся у Вам никогда не будет. А в случае двойной записи ошибка видна моментально, так как нет баланса. И считать ничего не надо, так как сразу есть все задолженности на счетах расчетов с дебиторами и кредиторами.
Так в общем случае момента, когда все операции завершатся у Вам никогда не будет.
Очевидно же, что имелись в виду операции за тот год, что считаем.
А в случае двойной записи ошибка видна моментально, так как нет баланса.
Задача: Найти операции которые не завершились (корабль с деньгами утонул)
В той модели, что я описываю (и про которую уверен, что она использовалась) видно сразу - просто листаем журнал (как бы он не назывался) и смотрим, есть ли правая часть (которая из подтверждений доставки заполняется).
В 'правильной' двойной записи делаем что?
Очевидно же, что имелись в виду операции за тот год, что считаем.
Так у Вас же операции имеют не нулевую длительность во времени. Значит не завершившиеся операции будут в любой момент времени, в том числе в полночь 1 января.
Задача: Найти операции которые не завершились (корабль с деньгами утонул)
Сальдо (дебиторская задолженность) на счетах расчетов с дебиторами в разрезе по контрагентам и, возможно, прочим аналитикам.
Так у Вас же операции имеют не нулевую длительность во времени. Значит не завершившиеся операции будут в любой момент времени, в том числе в полночь 1 января.
Разумеется есть. Но это, условно говоря, операции, начавшиеся в прошедшем году. А баланс на конец прошлого 1января - можно считать. И если на конец прошлого года что-то не сошлось - есть повод беспокоится.
Сальдо (дебиторская задолженность) на счетах расчетов с дебиторами в разрезе по контрагентам и, возможно, прочим аналитикам.
И вот это вот все изобрели сразу, без промежуточного этапа, выглядящего приблизительно как я описывал (и там все более-менее получается чуть ли не интуитивно) - не верю не разу. А если изобрели - как это выглядело в момент заявленной даты изобретения 'пять веков назад в эпоху Возрождения'
И я таки не понял, как найти операции. То что кому то деньги не дошли - это где-то балансы не сойдется что-то в духе "мы им посылали/они говорят, сколько у них сейчас есть". А как искать конкретную 'подвисшую' операцию?
операция - это не длящееся действие. Они имеют конкретный момент (определяемый договорм или законом). Если вы отгружаете частями товар, то как только вы отгрузили какую-то часть - фиксируется этот момент. И происходить переход обязательств - кладовщик уже не отвечает за отгруженный товар, а контрагент обязан вам оплатить. Вы отдали деньги караванщику - получаете обязательство караванщика. отдал деньги караванщик вашему филиалу - в вашем филиале появляются деньги, а у караванщика уменьшается обязательство.
Как раз по правилам бухгалтерского учета - только так.
Ну вот (старая) книжка 1773г. (Бедная моя голова - язык разбирать)
The nature and use of the terms Debtor and Creditor will be abvious from the confiderations following
I. Accompts in the Ledger confift of two parts which in their own nature are directly opposed to and the reverse of one another therefore are set fronting one another on opposite sides of the same folio. Thus all the articles of money received go to the left side of the Cash account and all the articles or sums laid out are carried to the right. In like manner the purchase of goods is posted to the left side of the account of the said goods and the sale or of them to the right.
Т.е. права и левая части операции описываются не так. Нет никаких правой и левой части одновременно. А есть "получили откуда-то" на этот счет (это слева) и "потратили куда-то" с этого счета. (это справа). По отдельности.
Ну те. оно, конечно, эквивалентно и одно в другое переводится, но понимание происходящего - другое.
В этой книжке, правда, где-то описывается разница между Journal и Ledger, и некой Waste-book но cходу прочитать и осознать все это я не могу.
Т.е. права и левая части операции описываются не так.
А теперь Вы смешали в кучу главную книгу и журнал операций.
А теперь Вы смешали в кучу главную книгу и журнал операций.
Возможно. Ладно, читать ту архаику у меня терпения нет. Возьмём книгу книгу поновее (1873г), с более современным языком (цитата с конца страницы).
The General Ledger contains the summaries of all the other books
General Ledger - я так понимаю, и есть главная книга. Которая с двойными записями и так далее. Вот только так получается вся эта двойная запись в ней не разу не про учет (он в этих остальных журналах ведется) операций. Она - аналитика учета.
Для случаев "деньги где-то" предусмотрен счёт "денежные средства в пути", если есть недоверие к современной банковской системе
Именно в таком формате оно позволяет проверять на ошибки. "Суммы справа и слева не сходятся - значит, деньги отправили, но куда-то делись или еще не доехали".
Но это не позволяет локализовать ошибку. А двойная запись - позволяет.
первая запись будет -деньги в офисе, +деньги в пути
вторая запись будет - деньги в пути, +деньги в филиале
Ваши активы в этом случае остаются неизменными, вся сумма денег. Но в любой момент вы знаете, из чего они состоят.
Но это не позволяет локализовать ошибку. А двойная запись - позволяет.
В смысле не позволяет? Видим запись без второй половины (даже считать никакие суммы и балансы не надо) - значит тут и сломалось. Начинаем смотреть, что мы для выполнения этой операции делали.
А с двойной записью - ну есть "-деньги в офисе, +деньги в пути", а есть ли соответствующая запись "- деньги в пути, +деньги в филиале" - еще найти надо. Их там таких целая пачка и непонятно, что чему соответствует. Нет, по какой-нибудь разнице балансов будет видно, что какой-то доставки в офис не хватает, но как найти, какой именно?
Кстати, как оно в двойной записи помечается, что эти две записи - это части единого целого? Ну вот когда видим вторую запись - как узнается, что это был перевод отправленный тогда-то и тогда-то?
Вот что тот способ, что я описываю, не позволяет - это быстро узнать "сколько денег у нас в пути?"
Но, это же не учет - это аналитика по результатам учета "что мы делали". Вон, цитата из книжка в моем сообщении выше вроде бы это и подтверждает.
Двойная запись - воспринималась как инструмент аналитики и поиска ошибок, куда сводилась информация из, собственно, учета. А сейчас приблизительно во всех описаниях, что я видел - эта главная книга описывается как источник правды о том, что произошло.
Видим запись без второй половины (даже считать никакие суммы и балансы не надо) - значит тут и сломалось
Так если у вас запись "одиночная" - то откуда вторая половина? а если запись двойная - то откуда вопрос? вы "или крестик, или трусы.."©
Их там таких целая пачка и непонятно, что чему соответствует.
Это вам непонятно.
Нет, по какой-нибудь разнице балансов будет видно, что какой-то доставки в офис не хватает,
Не по "разнице балансов", а по остатку на счете. Либо деньги на счете/в кассе, либо они в пути.
Если "путей" несколько (отправляете вы и караванщиками, и голубями) - делается соответсвующая аналитика - либо субсчета ДеньгиГолубями и ДеньгиКараванщиками, либо просто аналитический признак. а можете расширить аналитику до имени караванщика и клички голубя.
Но в любом случае при двойной записи деньги просто "сминусоваться" не могут - всегда будет "получатель" - либо деньги в пути, либо контрагент, либо работник, либо подотчетник...
Кстати, как оно в двойной записи помечается, что эти две записи - это части единого целого?
как вы, смотря на палку, понимаете, что ее концы - это части единого целого?
Так если у вас запись "одиночная" - то откуда вторая половина?
Она не одиночная. Она двойная. Просто половинки заполняются в разное время. В отличии от того, как сейчас объясняют.
Не по "разнице балансов", а по остатку на счете. Либо деньги на счете/в кассе, либо они в пути.
Ну вижу я что "деньги у меня в кассе" + "деньги в пути" + "деньги в кассе филиала" - равно тому, что должно быть.
Но мне-то хочется знать не только что что-то "в пути". Мне хочется узнать, какая именно операция "в пути". Куда смотрю?
Она не одиночная. Она двойная. Просто половинки заполняются в разное время.
Она или одна двойная, или две одинарных.
Но мне-то хочется знать не только что что-то "в пути". Мне хочется узнать, какая именно операция "в пути". Куда смотрю?
Вы можете по своей надобности либо шерстить все операции, либо завести аналитику. в первом случае вы потеряете на времени обнаружения, во втором - на времени обработки. Если вы отправляете деньги одним караванщиком - вам не нужна аналитика по каналам доставки. Если двумя - уже нужна. Если хотите аналитику по операцияс - заводите. но будьте готовы, что вы дали караванщику три раза по сто, а он отдал два раза по 150. И вам надо будет уже решать, за какую операцию он вам отдал. Но в любом случае, даже если вы не на ту доставку отнесете - у вас все рвно будет правильное наличие денег.
либо завести аналитику.
Да исходные данные то какие для нее. Из тех, что в двойной записи есть. (Т.е. дата,исходный счет,конечный счет, сумма,какая-то freeform объясняшка)
аналитика - это дополнительное свойство счета. То свойство, в разрезе которого вам хочется иметь дополнительную информацию.
Например, для взаиморасчетов с покупателями - вам нужно иметь аналитику по контрагентам. Потому, что сальдо расчетов с контрагентом может быть, грубо говоря, любого знака - Петя вам заплатил 100 рублей, а вы ему не отгрузили ничего. а Васе вы отгрузили на 100 рублей, но он вам не оплатил. А может получиться и так, что только аналитики по контрагентам вам будет мало, и придется заводить аналитику еще и по договорам.
Ну а для Денег в пути - можете, например, имя караванщика, или кличка голубя.
Ну а для Денег в пути - можете, например, имя караванщика, или кличка голубя.
Вопрос о том, как отследить конкретный платеж конкретного клиента. Было(в смысле пришли в офис и написали бумагу "прошу отправить в..", запустив процесс) три перевода по 100 золотых, банк пока отправили караванщиком 200 золотых.
Как считаем и как регистрируем (учет же) в рамках двойной записи, что вот те два перевода уже дошли, а этот последний - еще нет? Какое дополнительное свойство на счет "Деньги в Пути" добавляется, чтобы жизненный цикл этих переводов различить можно было?
Далее, для осложнения задачи - по дороге(отчет из филиала голубем прилетел, пока караван шел) выяснилось, что в том филиале в сейфах достаточно наличности и можно считать, что с точки зрения клиентов (но не банка) все три перевода выполнены.
Вопрос о том, как отследить конкретный платеж конкретного клиента. Был три перевода по 100 золотых, отправили караванщиком 200 золотых.
Караванщиком вы отправляете не "платеж клиента". вы отправляете свои деньги. Не на всех счетах должна быть аналитика. Вот вам пример: вы получили 500 рублей зарплаты, 100 рублей за шабашку, и 50 рублей взяли в долг у Васи. И в такси платите 70 рублей. Нужно ли вам знать, из каких доходов оплачено такси? как вы сможете это сделать?
Далее, для осложнения задачи - по дороге(отчет из филиала голубем прилетел, пока караван шел) выяснилось, что в том филиале в сейфах достаточно наличности и можно считать, что с точки зрения клиентов (но не банка) все три перевода выполнены.
И в чем вопрос-то?
Караванщиком вы отправляете не "платеж клиента". вы отправляете свои деньги.
Не важно. Все равно момент "ну все, с этим заявлением разобрались, все довольны" есть.
И в чем вопрос-то?
Как банк определяет, что по поводу вооон той бумажки "Прошу отправить 100 золотых в филиал на счет" шевелиться больше не надо и можно радостно похоронить все в архиве. Именно из этой двойной записи, а не еще какого-то рядом лежащего журнала учета. (Потому что General Ledger - источник правды, от которого все пляшут. Или все таки нет?).
Клиент принес деньги в ЦО с просьбой перевести их на счет в Муходрищенском филиале - дебет касса, кредит задолженность перед клиентом.
ЦО переводит в филиал: Кредит задолженность перед клиентом дебет задолженность филиала перед ЦО - обязательства перед клиентом переданы филиалу. И отправляет в филиал авизо - извещение, что "мы такому-то клиенту торчим столько-то денюх".(всё, мы, ЦО, клиенту ничего теперь не должны, должен филиал) Кредит касса дебет деньги в пути - отправлены деньги филиалу. И второе авизо, об корреспондентских расчетах - "мы вам там горшочек с 100 золотыми послали".
Филиал принимает первое авизо (поручение выполнить обязательство перед клиентом), и делает дебет задолженность перед ЦО, кредит задолженность клиенту. Выдает деньги из своей кассы - кредит касса, дебет задолженность клиенту (не хватает денег в кассе - ждет прихода каравана, занимает у соседнего менялы, или предлагает барыге разместить свободные деньги у него на время. Но это уже другая история).
Принимает второе авизо - делает дебет деньги в пути кредит Задолженность перед ЦО
Приходит караван - делает кредит деньги в пути, дебет касса.
В любой момент мы знаем, "где деньги, Зин". Причем все три последних события (которые в филиале) могут происходить в любой последовательности, это не нарушит баланса.
(вообще, в банках проводки наоборот, т.е. если для предприятия касса и р/с являются активами, то для банка они пассивы. но общий принцип примерно такой)
Кредит касса дебет деньги в пути - отправлены деньги. И второе авизо, об корреспондентских расчетах - "мы вам там горшочек с 100 золотыми послали".
Принимает второе авизо - делает дебет деньги в пути кредит Задолженность перед ЦО
И в этот момент караван со 100 золотым тонет. Надо шевелиться - оформить убытки, послать 100 золотых заново.
Т.е. кто-то должен отслеживать (по постановке задачи - пользуясь информацией только General Ledger - поэтому никаких дополнительных журналов выполнения авизо(или как оно правильно называется))
Плюс сами авизо могут потеряться, поэтому чтобы все работало, нужна бюрократия по их учету и логистике, что опять же, вроде бы, означает, что General Ledger в качестве источника правды недостаточно для учета происходящего.
Выдает деньги из своей кассы - кредит касса, дебет задолженность клиенту.
В общем случае - пытается выдать. Может не повести и денег в кассе не хватит - т.е. опять таки "платеж еще не прошел, банку шевелиться надо, чтобы выполнить обязательства". Или первое авизо просто еще не получили, коль в любой последовательности шаги. Тоже банку шевелиться надо.
Приходит караван - делает кредит деньги в пути, дебет касса.
И процесс еще не завешен. ЦО должен узнать, посылать ему деньги повторно или нет. И вот это "Все, хватит золотые посылать, довезли" - оно где и в какой записи у ЦО будет записано?
И (я слегка не понял) - ЦО задолженности филиала перед конкретным клиентом как-то считает? Если да - то еще логистика и учет выдачи клиенту из кассы филиала.
И в этот момент караван со 100 золотым тонет. Надо шевелиться - оформить убытки, послать 100 золотых заново.
Об этом прежде всего надо узнать. Никакой системой внутреннего учета этого не достичь. равно как и для вашей "палки с одним концом" нужна внешняя информация.
Узнали - оформляем убытки. за счет чего-то. Ведь убыток должен быть чем-то покрыт.
пользуясь информацией только General Ledger
Ну вот при сведении общего баланса это и вылезет.
В общем случае - пытается выдать.
Я так и написал - выдает при наличии, при недостатке средств - либо ждет, либо где-то кредитуется.
И процесс еще не завешен. ЦО должен узнать, посылать ему деньги повторно или нет.
Повторно - не надо. Либо произошло "событие" (караван утонул), и тогда действуем, либо при сведении общего баланса обнаруживаем сальдо на "деньги в пути", и разбираемся, почему.
Я допускаю, что что-то мог неверно описать, но лень всё расписывать. Я описал общий принцип. Поняли - хорошо. нет - увы, мне лениво тратить время. Хочется разобраться - учебников по учету много. Не хочется - ничего не поможет.
Мне там вчера пытались указать, что оно всегда будет, (ибо операции постоянно идут). Я, правда, не согласился и возразил, что баланс на достаточно старую дату можно и посчитать.
Хочется разобраться - учебников по учету много.
Этого сколько угодно. Но вся ветка начался с моих сомнений о том, что в момент, объявленный моментом изобретения, все так же работало. С неким алгоритмом, с которого, по моему мнению, все и началось (ибо он интуитивный). С описанием исторических алгоритмов все намного хуже.
Вторая половина спора - это (не)использование General Ledger в качестве источника правды. Моя позиция(даже слегка подтвержденная книжкой) - что это было заметно менее выражено, чем сейчас.
Вы выражаетесь как-то так, что вас не поймешь. как будто слегка в нетрезвом виде. где "там", кто возражал, что баланс считается не на любую дату - непонятно. что как было менее выражено - я не понимаю. поэтому, извините, "умываю руки".
где "там", кто возражал,
Но так как операции отражаются постоянно, то, в общем случае, баланса у Вас вообще никогда не будет.
что как было менее выражено - я не понимаю.
Тут цитата о том, что "The General Ledger contains the summaries of all the other books"
Т.е. источник правды - все эти были эти самые остальные other books, а не главная книга, как у меня складывалось впечатление по современным объяснениям.
Мне кажется он троллит. У меня дочки уже с 12 лет помогали жене, подрабатывающей на дому главбухом для нескольких фирм. И такие базовые понятия бухучета замечательно понимали.
Мне кажется он троллит.
Я не совсем троллю. Я пытаюсь показать, что обычная история "двойная запись была изобретена" - создает несколько искаженную картину.
Потому что дальше кажется, что изобрели сразу со всеми этим счетами "деньги в дороге".
Двойная запись на то и двойная, что подразумевает отражение каждой операции по дебету и кредиту. А так как каждая хозяйственная операция обязана иметь место и время, то растянута во времени она быть не может.
А так как каждая хозяйственная операция обязана иметь место и время, то растянута во времени она быть не может.
Ок. "Перевести деньги в филиал (кораблём, за месяц)" -не хозяйственная операция. А что? И как учитываетcя? В виде целого, чтобы знать, чтоб перевод завершен.
Нет конечно. Это несколько хозяйственных операций выполняемых в разных местах и в разное время.
А нулевая задолженность на счете в разрезе нужной аналитики и будет обозначать факт завершения всей цепочки операций.
Нет конечно.
А что это? И как учитывается?
А нулевая задолженность на счете в разрезе нужной аналитики и будет обозначать факт завершения всей цепочки операций.
Какой? Что(какие поля записи) используем для построения. Например, если баланс счета "деньги в пути" не нулевой - это же не означает, что вот конкретно этот перевод не завершился?
И как учитывается?
Я же написал. Несколькими последовательными операциями в разных местах и в разное время.
Например, если баланс счета "деньги в пути" не нулевой - это же не означает, что вот конкретно этот перевод не завершился?
Сальдо отслеживается не только в разрезе счета, но и в разрезе аналитик. Условно говоря, у Вас для каждого подотчетного лица свой листик в главной книге, где сразу видна его задолженность.
Я же написал. Несколькими последовательными операциями в разных местах и в разное время.
Которые нужно как-то линковать. В тех книгах прошлых веков я таких полей не увидел. Возможно, плохо смотрел, но читать это все достаточно тяжело.
Условно говоря, у Вас для каждого подотчетного лица свой листик в главной книге, где сразу видна его задолженность.
Вот это правдоподобно и похоже на то что было видно в старых книжках. А то когда начинают говорить про 'аналитики' в контексте прошлых веков - это как-то очень странно воспринимается.
А нужно знать, что не завершился вот этот конкретный перевод?
Нужно - ведите аналитику в разрезе переводов.
Не нужно - у вас есть первичные документы, что вы отдали караванщику 100 золотых, а он отдал филиалу 90. Или он отдает вам 10 золотых, или вы жалуетесь шаху, и караванщику секир-башка.
Все сложнее ибо вы жалуетесь шаху, караванщик жалуется шаху, классическое слово против слова, вас обоих на дыбу, а там кто первый дрогнет то и не прав.
Поэтому есть еще первичка - расписка, которая отдается взамен ликвидного актива, а 100 злотых это ликвидный актив.
И расписка эта будет погашена при возвращении выданного актива. И шах янычар направлять будет согласно расписке или договору в двух экземплярах.
Тут проблем и нет. И нужды в записях нет - ибо нет расписок нет и повода посетить шаха. А есть расписки и запись не нужна.
Проблемы когда расписки становятся активом. И надо уже учитывать то, чего не существует материально.
классическое слово против слова
Вы еще и читать и понимать не умеете? (Впрочем, немудрено, если вы 30 страниц 4 месяца пытаетесь прочитать и понять)
Выше русским по белому написано: Не нужно - у вас есть первичные документы, что вы отдали караванщику 100 золотых, а он отдал филиалу 90.
Проблемы когда расписки становятся активом.
Никаких проблем, кроме как в вашей голове. Это называется либо банкнота, либо вексель. А отношение суммы расписки к сумме учета этой расписки называются, соответсвенно, курсом или дисконтом, и зависят от доверия к выдавшему расписку (возможно, сроку и другим существенным параметрам)
Прошу прощения что потянулся за вами в бессмысленный спор о личностях, но изначально во фразе было емнип "никто до этого момента быстрее не осиливал", что несколько отличается от вашего толкования написанного и как следствие ставит под сомнение уже Вашу способность читать.
И кстати что там с РМО логиста? В новом релизе у 1с все уже прям из коробки?
"Вы думаете я вас не переиграю?"(тм)
о изначально во фразе было емнип "никто до этого момента быстрее не осиливал", что несколько отличается от вашего толкования написанного и как следствие ставит под сомнение уже Вашу способность читать.
Ничуть. Это говорит более чем достаточно о вас и вашей команде. Есть такой "закон соответсвия" - уровень конторы соответствует уровню нанимаемого персонала. Поэтому если "бизнес пишет ТЗ так, что 30 страниц понимаются 4 месяца", то и персонал подбирается соответсвующего уровня. Т.е. нормальные люди там не задержатся.
"Вы думаете я вас не переиграю?"(тм)
я не буду опускаться до вашего уровня, где вы задавите меня своим опытом (если вы помните Марка Твена)
Вы пытаетесь что-то "показывать" в предмете, в котором не разбираетесь. Выходит очень смешно.
Вы пытаетесь что-то "показывать" в предмете, в котором не разбираетесь.
Ну дак разумеется. Потому и спрашиваю. Вон там выше был вопрос про то, как начало (чего-то, что не хозяйственная операция) "отправили деньги" и конец "деньги дошли" в двойной записи искать надо. Что-то ответа не увидел. Послали в духе "так очевидно же, где второй конец палки".
Я, увы, не работаю со счетами и проводками в банке (занимаюсь комплаенсом и клиентскими данными), но из разговоров коллег понял что проводка (платежный документ) разбивается на две связанные полупроводки - кредитовая и дебетовая. Т.е. по одной идет списание со счета плательщика, по второй - зачисление на счет получателя.
Та самая "двойная запись".
Это если не касаться более сложных операций типа "мультивалютных проводок"... Там все еще сложнее. Но это уже банковское чисто, в обычной бухгалтерии вряд ли.
разбивается на две связанные полупроводки - кредитовая и дебетовая. Т.е. по одной идет списание со счета плательщика, по второй - зачисление на счет получателя.
Одновременно? Или все-таки бывает, что списали со счета плательщика в один день, а зачислили на счет получателя - в другой?
И чем это отличается от того, что я с самого начала описываю "сначала одну половину записи делаем, потом, в другое время - другую"?
Увы, не моя тема, так что подробностей не скажу.
Там есть операция линковки полупроводок, так что, да, возможно что списание и зачисление происходят в разные моменты времени. Как я понимаю, затем полупроводки нужны.
Аналогично в производственной компании. Там все сложнее. Есть заказ-наряд не проведение работ. Он основан на смете (стоимость работ и материалов). Дальше производятся работы, под них со склада выписываются материалы (которые стоят на балансе и имею некую стоимость). По окончании работ подписывается акт сдачи-приемки по которому потом выплачивается стоимость. И вот только тут все начинает сходиться - стоимость использованных материалов, зарплата рабочим, норма прибыли и т.п. Но между началом работ и окончанием проходит некоторое время "дисбаланса" - материалы со склада уже ушли в работу, а деньги за них еще не получены. И вот этот дисбаланс должен быть закрыт "первичными документами" - заказ-наряды, сметы и т.п.
Т.о. "бухгалтерия сходится" не когда сумма в БД равна сумме в кассе, но когда сумма в БД равна сумме в кассе + сумме по первичным документам которые не закрыты еще актами выполненных работ.
Так и с переводами (только проще) - полупроводка на списание суть заказ-наряд на проведение работ, полупроводка на зачисление - подписанный акт выполненных работ.
Но между началом работ и окончанием проходит некоторое время "дисбаланса" - материалы со склада уже ушли в работу, а деньги за них еще не получены. И вот этот дисбаланс должен быть закрыт "первичными документами" - заказ-наряды, сметы и т.п.
Вооот. Т.е. на самом деле есть еще какой-то журнал(может, не оформленный явно), который не обязан все время сходиться.
А General Ledger - это та его часть, где (иногда сильно синтетическими методами) все успело сбалансироваться.
Что, соответственно означает, что этот самый General Ledger - не источник истины "что у нас, вообще, происходило?", а только какой-то (удобный и полезный) результат того, несбалансированного списка "не хозяйственных операций".
Значит было две операции через транзитный счет.
Именно одновременно. Ибо деньги не могут быть "нигде".
Именно одновременно. Ибо деньги не могут быть "нигде".
Пример с кораблем и двумя филиалами? Ну вот как это может происходить одновременно, когда даже бумаги "Был произведён перевод на счет ABCD вашего филиала" везти надо.
Еще раз - речь идет не о том, как сейчас, а о том, как было в момент заявленного изобретения.
Двойную запись в том числе изобрели для того, что если одно лицо в попытке скрыть доходы от налогов сожжет все свои гроссбухи, вторая половина его записей окажется у контрагентов и таки попадет куда надо. И в том числе это стояло у истоков блокчейна в каком то смысле, как один из вариантов.
С двумя одиночными записями у вас происходит разрыв в учете актива.
Вы 50% своих денег отправили в банк.
Первая запись списала с вас актив.
До второй записи вы нищий, на вас плюют на улице и не пускают в рестораны. Женщины смеются вам в след. Собаки кусают вас за пятки.
Вы вынуждены бегать с листиком и искать - дошли ли деньги или нет, когда же наконец я снова стану богатым?
Вы по сути все равно переизобретаете двойную запись. Факт и ожидание следующего факта. Только в худшем варианте.
Вы по сути все равно переизобретаете двойную запись. Факт и ожидание следующего факта. Только в худшем варианте.
Вопрос не в том, что я изобретаю/предлагаю использовать. Вся ветка - про исторические практики/алгоритмы, которые, я подозреваю(уже, впрочем, подозревал - тут меня некое просветление догнало) и были худшими вариантами, чем то, что сейчас есть. Не могли же все сразу в современном виде начать использовать. О чем в беглых обзорах 'двойная запись была изобретена...' не говорится.
Причем в ветке мне несколько раз предлагали 'если мне надо' использовать что-то из современных способов и в современной терминологии, что ну вот совсем не то, что нужно, чтобы подозрения подтвердить/развеять.
Дело было не в налогах, а в борьбе с нечистоплотностью персонала. Если деньги в кассе уменьшились - то что-то должно увеличиться. Либо товар, либо чьи-то долги, либо прибыль
Уменьшится деньги могут простой записью что денег клиент дал меньше в этой же гроссбухе. Вот дал клиент 100 злотых и ушел, а записали 50 и ничего владелец не узнает даже.
А выдавши чек клиенту на 100, уже хозяин может с ним сверится, с записями клиента и надо вступать в сговор.
Это где так происходит - клиент бросает 100 денег и уходит?
Все-таки это не для учета подаяний было придумано...
Допустим в ресторанах. В сфере услуг.
Там вообще происходит так - заказывают у тебя допустим выпивку, которая в ресторане стоит дорого. А на улице тут же за углом дешево. И продаешь ты задорого, идешь на улицу берешь задешево, ставишь в бар и вроде как и не было продажи.
И тут всяческие варианты двойной записи очень приветствуются.
Но и схемы мутят в общем случае сложнее.
Если ты продал задорого и не отразил в своей амбарной книге - и тут приходит хозяин - атата по попе (расхождение и кассы, и товара ). Если отразил, но взял деньги из кассы, и купил еще флакон - и тут пришел хозяин -атата по попе, ибо в кассе недостача, в товаре излишек. Если на свои купил флакон, и тут пришел хозяин - атата, товар в излишке (товар на приход, хозяин обогатился, ты деньги просрал, и еще и жопа болит).
А если я купил, даже не я, и даже не у соседа, а друг на другом конце города, зашёл с рюкзаком этого добра как посетитель и совершил подмену в подходящий момент, то все уже сложнее. И стоимость системы слежения начинает приближаться к профиту. Поэтому двойная запись не только внутри своих счетов, но и наружу. То, что дебет у одного - кредит у другого. И мы можем свериться. И будет интересно хозяевам что дебет у одного не равен кредиту у другого.
Не, не факт. Я тоже, помнится, задавал такой же вопрос бухгалтеру: "если всегда сколько по дебету, столько и по кредиту - откуда у фирмы прибыль берется".
Это была вообще фееричная история... 1990 год, кооператив, для ведения учета пригласили бабку, уже просидевшую лет 15 на пенсии. А потом увидели рекламу "финансы без проблем", купили, поставили... я совместно с ней разбирался с "учетом на компутере". Она моментально просекла, и тыкая одним пальцем в клавиатуру, от которой сидела максимально отодвинувшись (по сути, тянулась к клавиатуре), вела учет...просекла, что ей теперь не надо рисовать ведомости и шахматки. Что просто достаточно правильно вводить данные... В общем, в результате были довольны все...
Так ответ простой. Операционная прибыль - это сальдо на 90-ом счете, возникшее из-за разницы между доходами от реализации и себестоимостью.
Я знаю ответ. сейчас. Но тогда я был студентом, причем специальности, весьма далекой от бухгалтерии. Да и вообще, понимание потребности учета тогда было весьма призрачным практически у всех, кроме собственно бухгалтеров. Только-только появились кооперативы. 1990-й
главбух, несколько фирм, из дому, дочка 12 лет... ну если фирмы уровня ларька, то да
А скажите, это правда, что двойная запись, это просто костыль, призванный скрыть факт, что бухгалтеры отрицательных чисел не знают?
;) знают они отрицательные числа, но у бухгалтерии не бывает отрицательных денег, для бухгалтеров это ересь. Потому что деньги это такой предмет, что если где-то они убывают - то где-то прибывают, в никуда исчезать не могут, потому что за исчезновение в никуда наступает секир-башка и прочие кары.
в никуда исчезать не могут
Ну, тогда из соображений симметрии, и появляться не могут? Ну мы же не замкнутую систему моделируем?
Именно.
зы. вы, наверное, хотите в дальнейшем подколоть вопросом "а как тогда появляется прибыль?", да?
Именно.
Пардон, я там свое сообщение после отправки отредактировал, добавив "не" перед словом "замкнутую". Так что просьба уточнить, "именно" что? Замкнутая система, или нет? В одном случае деньги ни исчезать, ни появляться не могут, в другом и то, и то без пробем. Т.е. как ответите, так и подколю :)
Вот когда до эмиссии денег доползём, тогда и будем говорить про незамкнутую систему. Да и то... В обороте деньги не появляются из ниоткуда, а происходящее у эмитента в вашем учёте не отразится )
Вот когда до эмиссии денег доползём, тогда и будем говорить про незамкнутую систему.
Это если про деньги. А если про обязательства (которые так же много и охотно учитывают) - оно незамкнутое.
Пообещал я кому-то 100 рублей подарить - обязательство "Я ему должен" из ничего взялось.
Но в двойной записи это обязательство совершенно искусственно балансируют каким-то счетом "Мои обещания"
Но в двойной записи это обязательство совершенно искусственно балансируют каким-то счетом "Мои обещания"
И если эти числа в разные книги руками вписывали, то сейчас или copy/paste, или вообще программа сразу в две таблицы добавляет.
Вы не можете кому-то пообещать и подарить 100 рублей. Это не ваши деньги, ни владельца бизнеса, ни учередителя, ни кого-то еще. Сначала вы обязаны передать эти 100 рублей себе в виде зп, вознаграждений, девидентов и т.д. Чтобы эта сумма отразилась в налогооблагаемой базе, чтобы было известно кто за эти деньги рассчитается налогами. И только после этого дарите кому и как хотите. А "пообещал" породит такие вопросы у налоговой в плане отмывки или прямого укрывательства от налогов что будете расхлебывать несколько лет.
Вы не можете кому-то пообещать и подарить 100 рублей.
Почему не могу? Могу. Все остальное, включая получить деньги, которые можно подарить - это уже другой вопрос..
А "пообещал" породит такие вопросы у налоговой в плане отмывки или прямого укрывательства от налогов что будете расхлебывать несколько лет.
А речь не про компанию, речь про принцип работы. Я, может, двойной записью личные финансы веду(смотри GnuCash). И вот зарегистрировал, что кому-то обещал сотню.
В этом случае это не регистрация свершившихся фактов и не нуждается в двойной записи. Это бюджетирование и планирование. Эта деятельность тоже автоматизируется на 1С но в бухгалтерской терминологии не нуждается. А вот когда ваше "обещание" - планируемые расходы перейдут к стадии реализации то вы отразите расход в терминах бухгалтерии.
В этом случае это не регистрация свершившихся фактов и не нуждается в двойной записи. Это бюджетирование и планирование. Эта деятельность тоже автоматизируется на 1С но в бухгалтерской терминологии не нуждается.
Как это не свершившийся факт? Это факт, что я обещал и зафиксировал свои появившиеся обязательства. Все остальное, про 1С, бухгалтерию прочее - не существенно.
В инструменте 'двойная запись' (а не каком-то другом) задача зафиксировать появившееся добровольное обязательство - решается именно добавлением абстрактного счета-объяснялки для балансировки записи. Нет разве?
"100р: Я должен X-у <-> Мои добровольные обещания"
Нет. Вы можете создать так называемый "забалансовый счет". Но это только чтобы вести заметки для себя. На таких счетах не ведут двойную запись.
Нет. Вы можете создать так называемый "забалансовый счет".
А этот забалансовый счет - разве не то, что я назвал абстрактным счетом-объяснялкой"?
Если нет - то как то же самое будет выглядеть с применением именно забалансового?
Забалансовые счета не используют двойную запись. Это просто памятка для вас. Создадите счет какой-то и будете туда плюсовать "мои обещания". Чтобы в любой момент видеть сколько наобещали. Когда отдадите физически деньги из кассы (с личного кошелька) с двойной записью, то дополнительно сами спишите (или автоматизируете с помощью каких-то признаков автосписания) с этого забалансового счета такую же сумму. Ну и всегда можете увидеть то самое сальдо по этому счету, чтобы знать сколько еще наобещали.
Вы ж не ПБУ обсуждаете, а принцип двойной записи. План счетов строго регламентирован на постсоветском и то не на всем. В других странах другой подход к организации плана счетов. Вы можете вести учёт хоть ракушек для своих целей, регистры для учёта налогового и стат государственного должны предоставить. И не все налоговые регламентируют регистры учета первички. Есть которым достаточно отражения на их БД электронной документации в их формате и все.
С чего бы? Долги, векселя там какие нибудь ходили Как оплата вполне себе в безденежные времена бартера. У денег ликвидность много выше, но обещание Жоры крышу предоставить это обещание и оно может быть номинирован в деньгах и это важный нематериальный актив
Векселя это официальный документ, который отразится как дебет счета 60 у того кто вексель выдал и кредит 60 у того кто дал. Но так как это средство оплаты то эти операции будут двойными со счетами за что дан вексель. Либо реализация товаров либо услуг. Крыши Жор никогда не отражались в бухгалтерии, пока они не стали официальными ЧОП-ами Жора и К. С этого времени операции как и полагаются обычные оплаты услуг по счетам.
Векселя это официальный документ, который отразится как дебет счета 60 у того кто вексель выдал и кредит 60 у того кто дал.
Гм.
200 лет назад грабители подошли к британскому джентльмену (т.е никаких 60-х счетов) и попросили денег под угрозой ножа. Наличности у джентльмена не было и он выписал вексел. Грабители по каким-то там соображениям на это согласились.
Поскольку он джентльмен аккуратный и образованный, то что он должен записать у себя в журналах (оформленных по правилам двойной записи). Именно двойной. Потому что все остальное - "фу, я же не дикарь какой, я за деньгами аккуратно слежу".
Прямо вот заведет отдельную книжечку "Выданные векселя" и туда впишет сумму. А когда уже придут за оплатой напишет в книжечки "Наличность" минус столько то, "Личные расходы" плюс столько то. Потому что Королева не примет объяснения что это было что-то не личное. Потом откроет третью книжечку "Выданные векселя" и там спишет такую же отрицательную сумму.
Прямо вот заведет отдельную книжечку "Выданные векселя" и туда впишет сумму.
У меня гуглится другое (1898г). Ну ли я не так текст понимаю.
Там названия счетов вида "Bill Receivable", "Bill Payable" фигурируют и двойная запись. А не просто одна строчка.
Там, впрочем, без абстрактных счетов обошлись, а нормально - персоналии (банки, люди) и взаимные обязатльства между всеми троими. Получилось, потому что третья сторона есть. Да и то думать надо - "Bills Receivable" вроде бы оно(плюс минус лапоть) и есть - "обещал денег, но еще не отдал" т.е. обещания.
+задолженнось по векселю, -капитал
обязательство "Я ему должен" из ничего взялось.
Обязательство - да, а вот деньги на него - из ниоткуда не возьмутся.
Кстати, еще один важный принцип забыли - "у предприятия нет ничего своего - всё кому-то принадлежит".
Обязательство - да, а вот деньги на него - из ниоткуда не возьмутся.
Деньги и гашения долга - это другая запись.
Кстати, еще один важный принцип забыли - "у предприятия нет ничего своего - всё кому-то принадлежит".
Да что же всех так на предприятие тянет-то? Речь идет о самом принципе регистрации и учета. Вот выше пример без всякого предприятия.
Причем даже не обязательно денег. Огород я обещал вскопать, без всякой денежной оценки - тоже обязательство, которое можно зафиксировать.
Да что же всех так на предприятие тянет-то?
Потому что бухучёт - это про деньги. И всё, включая обязательства, имеет денежную стоимость. А если не имеет - то не учитывается.
Например, надо ли учитывать лицензии на программное обеспечение, полученные бесплатно? С т.з. гражданского законодательства у вас всё хорошо, свободная лицензия это позволяет. А вот с т.з. налогового всё уже не так просто )
Бухучет в широком смысле это про управление. Притом хоть как нибудь про деньги классические оно было во времена золотого стандарта, когда Ваши активы на счетах не прыгали за день в разы без всякого изменения, что придавало всему этому несколько больший смысл, чем теперь. Та самая валюта баланса. Потому что когда у тебя на складе продукция номенированная в валюте и валюта эта летит вверх тебе выгоднее не продавать, как бы это странно не звучало.
Классически бухучет это дорожная карта перехода активов из одного качественного стостояния в другое с количественными их оценками этих состояний в процессе достижения целей управления.
Заключить столько то договоров, закупить столько то товаров, приобрести и ввести в эскплуатацию столько то основных средств, взять в лизинг столько то, на операционные счета положить столько то, из потоков денег выделять на оплату труда и т.д. И бух, в классике, а не только обслуживающий интересы ФНС куда он выродился, отслеживает изменение этих активов в динамике в целях достижения целей организации, которые могут быть совершенно не про деньги в некомерческой организации.
И если за обещание вскопать огород с вас потребуют бутылку, а не деньги, вы заведете счет актива "бутылки" и будете там накапливать бутылки что бы рассчитаться за вскопанный огород и будете учитывать обещания вскопать, потому что это необходимые объекты учета в целях достижения ваших конечных или промежуточных целей - урожая.
Бухучет в широком смысле это про управление.
Всё-таки про деньги. Т.к. даже бутылка - тоже выражается в деньгах, и в какой-то момент может оказаться, что выгоднее вскапывать не за бутылки, а за иное вознаграждение, например. Или не оказаться.
А вот всё остальное, о чём вы говорите - это уже аналитика поверх учёта. Которая, к тому же, может учитывать и другую информацию.
Потому есть бухгалтер, а есть экономист, оба имеют отношение к финансам, но функции - разные.
которые могут быть совершенно не про деньги в некомерческой организации.
И там тоже про деньги, если говорить конкретно о бухучёте.
Если КО - это деньги ради денег, грубо говоря, то НКО - это деньги ради чего-то другого. Но эта цель - уже вне зоны ответственности бухучёта (кроме, разве что, контроля законности проводимых операций - которая, впрочем, есть и у КО, и у бюджетных организаций, разной будет специфика этого контроля).
Забудьте про отчётность. База бухучета в его современном виде возникла даже до появления некоторых государств, не говоря об их налоговых и их пбу.
Деньги там на счетах в основном потому что они наиболее ликвидны. А они не всегда ликвидны. Иногда они обесцениваются быстрее, чем вы их в регистры успеваете заносить, в отличии от бутылки.
И огород вам вскопают за бутылку, а не пятьсот рублей сегодня, а завтра уже тысячу, смотря как напечатают сверху. У вас рука устанет переоценивать и прикидывать хватит денег или нет
Деньги на счетах не потому, что они ликвидны, а потому, что они всеобщий эквивалент. Он может девальвироваться, но тем не менее, на территории государства он эквивалент, средство платежа и мера измерения.
И огород вам вскопают за бутылку,
ну, можете вести учет в поллитрах, если вам это привычнее. Но не везде такая валюта принимается.
Если обязательство не имеет денежной оценки и денежных последствий - оно не имеет смысла. Потому оно может и не отражаться. Если вы обещали соседке вскопать огород, и еслине вскопаете, то она на вас обидится - это одно. А если вы не вскопаете, она на вас обидится, а колодец только у нее, и вы воду будете возить с собой, или покупать у нее, или бурить себе скважину - это другое. И тогда денежная оценка имеет вполне реальный смысл (вы можете поразмышлять, и решить - тратить ли сейчас много денег на свою скважину, или вскопать самому (а это ваше время, т.е. деньги), или нанять за деньги васю..)
Отрицательные числа в проводке - это красное сторно
И, в общем, правильно делают.
Я, когда сводил свой первый баланс (ну, естественно, как почти повсеместно в те годы, "не совсем белый") вроде подогнал все цифры, по оборотке все прекрасно сходится, а баланс (форма) не формируется...Оказалось, кредитовое сальдо по кассе...Математически-то оно верно, но как вы себе представляете кассу "с отрицательным числом денег"?
Математически-то оно верно, но как вы себе представляете кассу "с отрицательным числом денег"?
А не надо представлять, надо правильно интерпретировать. Ну вы же понимаете, что разности двух натуральных чисел с эквивалентностью по отношения к прибавлению и/или уменьшению обоих чисел на одну и ту же величину, полностью эквивалентны целым числам со знаком?
Получил зарплату, плюс, заплатил за что-то кредитной картой - минус. А уж сумма - как повезет.
Ну и как вы представляете отрицательный остаток денег в кассе?
Не обязательно в кассе. можете в кармане. Ну, допустим, -50 рублей 50 копееек. чтоб точно знать, что если туда закинуть сотку, там появилось 49.50 мелочью...
Ну и как вы представляете отрицательный остаток денег в кассе?
Да почему вы все время говорите о кассе, как исключительно о ящике с наличными деньгами? Я специально о кредитной карте сказал.
Ну а я специально сказал о кассе как о ящике с наличкой. Именно это подразумевается в учете под словом "касса".
а "отрицательный остаток по карте" - это сумма двух остатков: 0 по вашему дебетовому счету, и задолженности по кредитному счету, отражаемой со знком "-"
Ну а я специально сказал о кассе как о ящике с наличкой. Именно это подразумевается в учете под словом "касса".
Ладно, но я все равно не понимаю, зачем в одной таблице нужно хранить уходы, в другой приходы а не одну с положительными и отрицательными числами. Все равно, хоть так, хоть сяк, как минус получили, значит ошиблись. Но если колонка одна, много чего (типа динамики по времени) считать проще.
а "отрицательный остаток по карте" - это сумма двух остатков: 0 по вашему дебетовому счету, и задолженности по кредитному счету, отражаемой со знком "-"
O! А вот и отрицательное число :)
Но если колонка одна, много чего (типа динамики по времени) считать проще.
А когда тысяча пользователей хотят узнать какие есть товары на складе а с другой стороны сотня бухгалтеров хочет внести операции с кассой все зависнут в ожидании блокировок?
Потому и гроссбухи были разные, кому то нельзя знать сколько есть в кассе и на счетах, кому то нет смысла ждать пока заполнят кассу и банк, его интересуют данные совсем из других книг. Так и сейчас не все операции с кассами и счетами относятся к товарам. Зачем блокировать всю систему когда можно работать только со своей частью.
Не "в одной приходы в другой уходы", а это две разных сущности. Дебетовый счет - это ваши деньги. За которые вам нужно начислять проценты (да еще со сложными условиями любят это делать - например, если у вас среднедневной остаток по счету в течение месяца больше N рублей). а кредитный счет - это счет, по которому проценты надо брать с вас (тоже по каким-то условиям - беспроцентный период, минимальный платеж, лимит и все такое)
За которые вам нужно начислять проценты (да еще со сложными условиями любят это делать - например, если у вас среднедневной остаток по счету в течение месяца больше N рублей). а кредитный счет - это счет, по которому проценты надо брать с вас (тоже по каким-то условиям - беспроцентный период, минимальный платеж, лимит и все такое)
Это в будущем, а на сегодня можно и сложить со знаком. если самый большой начальник спросит, насколько он богат. А вот что будет завтра, так это можно по доп.флагам и знаку пересчитать. За один проход по таблице. Всяко же проще сложить два целых числа (копеек), а не разбираться. что из чего вычитать и куда записывать в зависимости от знака результата. Ну не маразм же ручками эмулировать арифметику с отрицательными числами?
Вообще, нормальные люди при проектировании архитектуры думают о будущем... и минимизирую себе сложность "пересчетов по флагам и знакам".
Вы же не хотите, чтобы на вопрос "сколько у меня денег на счету сейчас?" - банк вываливал вам операции с даты открытия счета: "нате, считайте!"?
Вы же не хотите, чтобы на вопрос "сколько у меня денег на счету сейчас?" - банк вываливал вам операции с даты открытия счета: "нате, считайте!"?
Вообще я хочу, чтобы в некоторых случаях банк так и делал.
А то я недавно попытался историю операций в домашнюю программу перенести - так выяснилось, что пара банков, не дают операции старше n лет.
Все свели в 'баланс на дату', считают от нее, а операции старше этой даты в малодоступный архив отправили.
Вы же не хотите, чтобы на вопрос "сколько у меня денег на счету сейчас?" - банк вываливал вам операции с даты открытия счета: "нате, считайте!"?
Тут же уже писали о всяких закрытиях разных "дней", т.е. о типа кэшировании?
Так же как и отрицательное количество на складе, пересорт и т д. Отрицательное количество не в кассе, а на счете учета. Не отождествляйте, если хотите вырасти над собой, конечно.
Вот так и мучились до изобретения двойной записи. А сейчас отработал час - возникла задолженность работодателя перед Вами по зарплате. Потом эта задолженность была погашена денежными средствами. Пришли на кассу магазина с банкой пива - возникла задолженность перед магазином на стоимость этой банки. Оплатив кредитной картой покрыли задолженность перед магазином, но получили задолженность перед банком. И так далее. Закон сохранения энергии (ценности в денежном выражении).
Вот так и мучились до изобретения двойной записи.
До распространения отрицательных чисел. И компьютеров. Я же писал выше, что эти два варианта (разности положительных чисел и целые числа со знаком) полносью эквивалентны.
Закон сохранения энергии (ценности в денежном выражении).
Так энергия знак имеет. Нет в физике никаких двойных записей.
Я же писал выше, что отрицательные числа (красное сторно) несет совсем другой смысл.
Ладно, пришлось таки посмотреть, что это такой легаси-способ визуального обозначения отмены ошибки. И таки тут минус не требует какой-то специфической обработки, отличающейся от стандартной математики. Неверная запись X, потом -X, потом правильная Y. Итого X-X+Y=Y. А заклинания можно и не произносить.
Не понял, почему легаси? Придумали иной способ, который уменьшает обороты, а не увеличивает их?
Потому-что, ну какой красный цвет в базе данных?
Для БД, в зависимости от реализации, это или флаг, или отрицательное число в проводке.
Ну и тогда, может, пора бухгалтеров переучить? Я именно про это. А то получается, то все эти заклинания для разрабюотчиков лишняя работа и источник дополнительных ошибок.
Может, разработчикам нужно научиться?
Если Вы предлагаете клиентам переучиваться, вместо того, чтобы адаптироваться самому под их требования, то Вам не позавидуешь
Если Вы предлагаете клиентам переучиваться, вместо того, чтобы адаптироваться самому под их требования, то Вам не позавидуешь
А это от специализации зависит. Если меня попросят рассчитать динамику распределения тепла, используя какую-нибудь теорию теплорода, то фиг я это сделаю. В смысле используя устаревшие и неверные физически формулы.
Без разницы, в подавляющем большинстве случаев, если Вы предлагаете клиенту переучиваться - это потеря клиента.
Если речь идет о клиенте из соседнего отдела фирмы, то и хорошо. Так бы фирма деньги потеряла, если бы использовала результаты неверного моделирования для, например, создания опытного образца, а так, наоборот.
Из соседнего отдела - это коллега, а не клиент. Клиент приходит с деньгами. И как только Вы говорите, что ему нужно переучиваться, он уходит с этими деньгами к конкурентам.
Альтернативный вариант - тендер. Но там аналогичная ситуация.
Из соседнего отдела - это коллега, а не клиент. Клиент приходит с деньгами.
Иногда случается внутренний "хоз.расчет".
Вот иногда и будут у Вас доходы )))
Это "иногда" меня вот уже 25 лет как кормит :)
И даже не стесняетесь публично заявлять, что паразитируете на коллегах, которые вынуждены оплачивать то, что им не нужно? Браво!
А как вы пришли к такому выводу? От того, что я кавычки поставил? Так это я просто не помню, как оно официально на английском называется, когда у подразделений свои условные бюджеты. И не знаю, насколько это распространено в других фирмах из S&P 500.
До распространения отрицательных чисел. И компьютеров.
Тут дело вот в чем, как я понимаю. На самом деле 'закон сохранения' денежный средств и обязательств - он не совсем как в физике.
Если я кому-то должен 100 рублей и кто-то другой должен мне 100 рублей - это не означает, что никто никому ничего не должен. Так будет только когда мы об этом договоримся.
И эти два случая надо различать. Нельзя иметь одно число и считать, что если <0 - то это я должен, а если >0 - это мне должны.
А если мы различаем - то все обязательства имеет смысл считать строго положительными.
Если я кому-то должен 100 рублей и кто-то другой должен мне 100 рублей - это не означает, что никто никому ничего не должен. Так будет только когда мы об этом договоримся.
Бинго!
Я даже больше скажу - если вы должны кому-то по одному договору 100 рублей, и этот кто-то должен вам по другому договору 100 рублей - это не значит, что никто никому не должен, пока вы с ним не договоритесь (проведете зачет)...
И эти два случая надо различать. Нельзя иметь одно число и считать, что если <0 - то это я должен, а если >0 - это мне должны.
Хороршо, если таковы првила игры, то пусть будет.
А если мы различаем - то все обязательства имеет смысл считать строго положительными.
А вот это уже пережитки прошлого. Все равно, кроме положительного обязательствав нужно еще и направление хранить. К себе плюс, от себя минус. А то получается, как в том анекдоте:
Мама, а почему, мы, когда варим сосиски, у них кончики отрезаем?
Не знаю дочка, еще бабушка так делала, спроси ее
Бабуша, и т.д. и т.п.
А вы что, до сих пор варите соссиски в той маленькой кастрюльке?
Все равно, кроме положительного обязательствав нужно еще и направление хранить. К себе плюс, от себя минус.
Как раз для этого у счёта есть дебет и кредит.
А вот толковать Д и К как плюс или как минут - надо уже в зависимости от того, счёт учитывает активы или пассивы. Потому что уменьшение активов (денег в кошельке) - это "минус", а уменьшение пассивов (долгов) - это "плюс".
То есть да, не всегда к себе - это плюс, а от себя - это минус.
уменьшение денег в кошельке - это "минус
Угу, к количеству денег в кошельке прибавляем отрицательное число (транзакция была "от себя").
уменьшение "долгов" - это плюс.
А теперь к отрицательному числу прибавляем положительное ("к себе"). Итого, совершенно единообразная обработка транзакций...
Угу, к количеству денег в кошельке прибавляем отрицательное число (транзакция была "от себя").
А теперь то же самое со счетом 'Мои долги'. Когда я деньги от себя кому-то отдал. Добавляем (потому что от себя) отрицательное число - и получаем непонятно что.
Я в общем, согласен, что вот такие 'Мои долги' можно было бы и в отрицательную сторону считать (т.е. там сумма всегда с минусом) и тогда все будет правильно, но обработку оно ни разу не упростит - просто if-ы будут в разных местах в другую сторону. Но их количество останется как бы не таким же.
Я в общем, согласен, что вот такие 'Мои долги' можно было бы и в отрицательную сторону считать (т.е. там сумма всегда с минусом) и тогда все будет правильно
Именно так.
но обработку оно ни разу не упростит - просто if-ы будут в разных местах в другую сторону. Но их количество останется как бы не таким же.
Да почему же? В моем варианте логика появляется лишь в моменте появления транзакции, да и то, если окно/диалог, где она добавляется, одно, а исчезает при коррекции всех счетов. И при суммировании всех/части счетов.
Угу, к количеству денег в кошельке прибавляем отрицательное число
Да, вот только отдана-то не отрицательная сумма, а то вообще получается, что она не отдана, а наоборот - получена в кассу...
А теперь к отрицательному числу прибавляем положительное
А "к себе" ничего не пошло - долг-то ушел "от себя", с чего вы уменьшение положительным числом записываете?
Тут фокус в том, что "потребитель" смотрит не на транзакции, а на итоговое сальдо, положительное оно или отрицательное. А что там в потрохах поступление на счёт, списание со счёта, исправление ошибок как с прибавлением, так и с уменьшением суммы - и их надо отличать от поступлений и списаний, и хранить журнал всех транзакций - его не волнует до тех пор, пока не возникает необходимость разобраться "а куда это у меня деньги делись?".
А поскольку во всех первичных документах - указывается только положительная величина, а 100 рублей не равно минус 100 рублям, то вы потом не докажете, что правильно посчитали деньги, потому что у вас формально не сойдутся значения.
Потому в БД можно хранить как угодно, но отображаться оно должно так, как должно, и чтобы никаких расхождений по знаку с первичкой.
А поскольку во всех первичных документах - указывается только положительная величина, а 100 рублей не равно минус 100 рублям, то вы потом не докажете, что правильно посчитали деньги, потому что у вас формально не сойдутся значения.
Ну вот. А сразу так объяснить нельзя было? И сразу понятно, откуда эта 'традиция' пошла и почему все еще живет.
Этого пунктика во всяких популярных объяснениях 'как работает двойная запись' я никогда не видел.
Этого пунктика во всяких популярных объяснениях 'как работает двойная запись' я никогда не видел.
Это не к вопросу о двойной записи, а к принципу "отрицательных денег не бывает".
А вот разделение счёта на дебет и кредит - уже к вопросу о двойной записи как способ реализации указанного принципа. Ну и заодно не спутаете расход (положительное число ибо так в первичке) с корректировкой ошибки путём уменьшения (где будет как отрицательное число).
Да, вот только отдана-то не отрицательная сумма, а то вообще получается, что она не отдана, а наоборот - получена в кассу...
5 + (-2) == 5 - 2 == 3
А "к себе" ничего не пошло - долг-то ушел "от себя", с чего вы уменьшение положительным числом записываете?
-5 + 2 == -(5-2) == -3
Так в учёте не нужна итоговая сумма, важны сами операции. Как отличить "-2" потому что это расход, и "-2" потому что это исправление ошибки?
Плюс еще вопрос, а почему вы долг минусом считаете? А если это вам должны?
Не многовато ли толкований и интерпретаций на знаки числен навешано в простом учёте операций? Особенно когда надо будет проверить правильность их учёта?
Повторяю - с точки зрения учёта не важно, что там у вас итого, важно, чтобы всё было правильно учтено.
Как отличить "-2" потому что это расход, и "-2" потому что это исправление ошибки?
Отдельным полем со ссылкой на ошибочную операцию. А так, было +2 (ошибка) прибавили -2 (отменили) +2+(-2) = 0. Что не так? Взяло и само исправилось.
Плюс еще вопрос, а почему вы долг минусом считаете? А если это вам должны?
Я считаю минусом свой долг. Чужой мне - плюсом (или никак - ведь его еще не отдали?)
Еще раз, вы вместо нормальных математических знаков +/- используете слова дебит/кредит, а математический минус -вместо флага. Кажется логичным - наоборот.
Кажется логичным - наоборот.
Да объяснили же уже. Если есть бумажка "Я обязуюсь заплатить 100р" - то именно "100р", без всяких знаков и хотят видеть в книге учета.
В древнем бумажном варианте просто на странице "Мои долги" книги учета так было и особого смысла это менять - нет.
Да объяснили же уже. Если есть бумажка "Я обязуюсь заплатить 100р" - то именно "100р", без всяких знаков и хотят видеть в книге учета.
Видеть - это одно, привыкли вот уже сколько веков, так привыкли, но обрабатывать и хранить можно уже по-человечески? Когда мне дают теплоемкость в единицах килокалории/(фунт*градус Фаренгейта) я, перед тем, как считать, все в СГС перевожу, и на выходе сантиметры обратно в дюймы.
Еще раз, вы вместо нормальных математических знаков +/- используете слова дебит/кредит, а математический минус -вместо флага. Кажется логичным - наоборот.
Это потому, что вас не хотят грузить дополнительными сведениями, и приводят сильно упрощенные примеры.
В реальности счета учета имеют еще свойства - активный, пассивный, и активно-пассивный. На активном не может быть кредитового (отрицательного) сальдо (остатка) - т.е. вы не можете выдать денег из кассы больше, чем там есть (не можете перевести больше денег, чем есть, не можете отгрузить больше товара). а на пассивном не должно быть сальдо дебетового (пассивы - это источники средств предприятия, например, уставной капитал). Т.е. "точек контроля" немного больше. Но это уже не тема объяснений...
Т.е. "точек контроля" немного больше.
Да ладно, проблема, переход через ноль запретить.
Пробовали, предприятие стопориться чуть больше чем за пол дня.
в учете так же есть принцип SOLID (может полностью, а может частично). Линейные сотрудники должны вводить первичку. Они ее вводят хорошо, если они видят расход на 100 штук они должны вводить расход на 100 штук. И программа должна им позволять делать их работу правильно. А работу контроллеров шерстящих как так получилось что остаток был 50, а расходовали 100 это уже не дело тех, кто вводит расход. Вводящие расход видят 100 отгружаемых штук и вводят то, что видят и за это им зарплату и платят. А за поиски несоответствий отвечают специально обученные люди и им за это тоже платят. Поэтому ничего запрещать не надо.
Отдельным полем со ссылкой на ошибочную операцию. А так, было +2 (ошибка) прибавили -2 (отменили) +2+(-2) = 0. Что не так? Взяло и само исправилось.
Вот, вам еще и поле понадобилось...
Я считаю минусом свой долг. Чужой мне - плюсом (или никак - ведь его еще не отдали?)
Вот, вы начинаете интерпретировать на уровне учёта к тому же...
А учёт - он должен быть дебилоустойчивым настолько, насколько это возможно. Потом интерпретируйте его данные как хотите.
Как это хранить в базе - вопрос 100500-й на самом деле. Но отображаться для пользователя все операции должны так, как должны. Потому что для идиота-проверяющего чиселка в первичном документе должна совпасть с чиселкой в учёте, и он не должен даже думать о том, которую из операций сложения или вычитания вы там применили.
Бухучёт - это на самом деле очень просто, но весьма занудно и крайне стрёмно в плане ответственности. Откуда и все его заморочки.
Вот с точностью наоборот, бухучет это очень сложно и крайне интересно, а ответственность ну не на линейных же бухах?
Взять первое правило бухучета - бухучет должен приносить прибыль. А дальше делаем табличку для каких счетов какие количественные минуса мы просто списываем в утиль, потому что разбираться с ними дороже, чем штрафы заплатить. Притом табличка эта динамическая. И дальше уже поднимаем флаги на разбор когда эти значения превышают критические в заданном периоде. Как Вам такая задачка, Илон? И это ж только поверхностные задачи оптимизации, еще ж есть и поглубже задачи - просчитать бутылочное горлышко процесса, возможный градиент увеличения показателей в зависимости от изменения состава активов во времени, локальные и абсолютные максимумы условной прибыли в зависимости от возможных распределений активов по времени и составу и т.д.
При том, что стоимость актива при мультивалютном учете у вас динамически плавает.
А вы говорите очень просто и занудно.
Комбинаторика всегда затягивает как пасьянсы.
бухучет это очень сложно и крайне интересно
Сдается мне, что путается учет (который, я согласен с другим комментатором) должен быть тупым (и желательно вообще автоматическим) и принятием решений (и выяснением итого) по тому, что учли.
Причем путается давно.
Потому что интерпретировать "Лицо A отдало лицу B 100р налички" можно по разному (То ли долг отдали, то ли подарили, то ли еще что), а факт вполне однозначный - 100р хозяина сменили.
Есть же еще учет учета. Учет, повторюсь, должен приносить прибыль. У учета есть себестоимость, которая не должна превышать получаемой ценности от его ведения (чувствуете уже глубину наблюдателя за наблюдателем?) и ответственность линейных операторов и их руководителей разрабатывать схемы минимазиции этой себестомости и знать их предел.
Опять же нет "тупого" учета, тем более автоматизированного.
Если Вы ставите вентиль и прибор со стрелочкой на трубу, распределяющего Ваш актив, то Вы в такие дебри по калибровке и сертификации и минимальным/максимальным объемам продажи влазиете, в том числе и по учету за этими приборами и за операторами этих приборов, что еще непонятно что легче было.
Вернемся к 100 рублям. Это так то ближе к банковской теме наверное - где 100 рублей "тупо" сменили счет. Но даже там на эту транзакцию налагают массу проверок от регулятора и так же интерпретируют на предмет возможных нарушений вплоть до блокировки счетов.
И центральный вопрос - а зачем вообще учитывать приход 100 рублей без сопутствующей аналитики? Что бы знать сколько у вас денег на кармане? Так достали лопатник и пересчитали - все проще, чем записки записывать.
по поводу примера из предыдущего комментария:
Потому что интерпретировать "Лицо A отдало лицу B 100р налички" можно по разному (То ли долг отдали, то ли подарили, то ли еще что), а факт вполне однозначный - 100р хозяина сменили.
А есть (а как называются системы?) где это учитывается как
100р: -Моя наличность +Наличность B (запись номер X)
А потом отдельно, после выяснения "что это было?", в другом журнале уже записывается
100р: -Моя наличность -Мои долги (Смотри X)
Вариант этой процедуры называется "процедура закрытия месяца", когда недостающую аналитику и количественно-стоимостные показатели дописывают к записям первички. В том числе и себестоимость. В классическом бухучете это есть.
В рабочем периоде операторы вводят первичку. Первичка имеет свой ID в виде номера/даты/вида документа. Какая то аналитика вводится сразу. Остальную дозаполняют уже в процессе закрытия какого то периода. Часть операций может быть интерпретированна сразу же, часть бух сидит прикидывает хрен к носу как отразить в учете, что бы меньше заплатить дядям, а больше оставить себе.
Вот с точностью наоборот, бухучет это очень сложно и крайне интересно,
Учёт как раз не так сложен. Сложно то, что потом экономисты делают с отчётами, которые делаются по данным учёта. Учёт же- скрупулёзен.
а ответственность ну не на линейных же бухах?
И на них тоже, если правильно составить должностные инструкции. Причём вина может быть не только в форме умысла, но и неосторожности.
Взять первое правило бухучета - бухучет должен приносить прибыль.
Бухучёт - это вообще расходная статья бюджета, как и ИТ - если, конечно, это не бух-аутсорсер или не ИТ-компания соответственно.
В классическом марксизме же бухгалтер вообще не считался создающим прибавочную стоимость, так что там еще хлеще было )
Как Вам такая задачка, Илон?
А эти описанные вами задачки - не к бухгалтеру, а к экономисту. Который, впрочем, в бухучёте разбирается и при желании может выполнять функции бухгалтера, но всё-таки это другая роль. Ну или сеньор бухгалтера можно считать немного экономистом, ага )
Проще говоря, экономическая аналитика - это уже более высокий уровень абстракции, чем учёт. Хотя и основывается на его данных (но не только).
А так-то да, я с вашими задачками согласен )
Учёт же- скрупулёзен
Вот смотрите, бухгалтеру нужно оценить кучу песка на дворе. Он может скурпулезно считать пещинки или оценить ее по форме/высоте гораздо менее скурпулезно в целях, достаточных для сути экономической деятельности.
но и неосторожности
Есть статистическая "ошибка оператора", условных 5% из-за того, что человек не совершенен. Ее уменьшают так же статистическим "чекрыжинием", проверкой вторым оператором. А штрафовать за то это Вы уже на роль бога замахнулись, наказывать за первородный грех, не надо так. Ничего кроме воооот таааакооой дыры в карме Вы от этого не получите, никакой дисциплины и прибылей, поверьте. Многие пробовали никому не понравилось.
расходная статья бюджета
вот пусть учитывают как хотят, товар это тоже расходная статья бюджета в каком то смысле, закупать, хранить, инвентаризировать, передвигать. Бухучет из просто кучи активов неясных делает из организации организацию. Информация об организации это тоже актив, актив очень дорогой, стоимость его равна стоимости аудита. При продаже той же фирмы вдруг оказывается что наличие этой информации и налаженной системы учета стоит хорошеньких денег, хотя сплошные расходы, кактак?
не считался создающим
Предположу что считался уменьшающим себестоимость, но я не спец по экономическому марксизму, в бутылку не полезу.
не к бухгалтеру, а к экономисту
Огромный примат интересов государства в бухгалтерии это все таки наш местный перекос. Некоторые считают что фин-отдел это вот кошелек генерального и не больше. Тоже ж перекос.
Бухучет в том или ином виде позволяет делать срезы структуры активов/пассивов во времени, т.е. иметь полную информацию для управления производственным процессом, только что это в какой то момент стало не модным. Впрочем я видел фин.учет на двойной записи, ровно как и бух учет на обычных регистрах, емнип.
Вот смотрите, бухгалтеру нужно оценить кучу песка на дворе. Он может скурпулезно считать пещинки или оценить ее по форме/высоте гораздо менее скурпулезно в целях, достаточных для сути экономической деятельности.
Похоже, мы где-то друг друга не понимаем... Бухгалтер вообще не полезет оценивать кучу песка - это не его зона ответственности. Он сообщит соответствующим специалистам, что песок по действующим правилам учёта учитывается по таким-то показателям. Те его измеряют, составят акт инвентаризации - а вот по акту уже бухгалтер учтёт этот песок в результатах инвентаризации.
Есть статистическая "ошибка оператора", условных 5%
Как я уже сказал - не только умысла, но и неосторожности. Как минимум КоАП РФ ему всегда светит, а там никаких "5% на ошибки оператора" не предусмотрено.
Есть нормы, условно, "усушки и утруски" - но они касаются материально ответственных лиц. С которых могут стрясти стоимость недостачи, причём не как с обычного работника - в пределах месячно зарплаты, а в полном объёме. Но бухгалтера это касается только если он кассир, или вдруг по совместительству кладовщик какой-нибудь.
Есть ситуации "на усмотрение работодателя" - но там ответственность в пределах месячной зарплаты в любом случае, а по факту в пределах премии, но это уже несколько другая тема.
вот пусть учитывают как хотят, товар это тоже расходная статья бюджета в каком то смысле, закупать, хранить, инвентаризировать, передвигать.
Товар - это уже "другое" ) Хотя да, это всё производственные затраты, и там тоже всячески стараются экономить. Но хотя бы производственные...
Предположу что считался уменьшающим себестоимость
Он там нахлебником считался, как и сам буржуй, если кратко ) Не того чтобы бухгалтер вообще ничего не делал и только деньги получал, но тем не менее - затраты на него непроизводственные. Там и с услугами непросто было - те услуги, которые связаны с транспортировкой товара потребителю - те в прибавочной стоимости участвуют, а остальные - нет. Ну, в наше время это бы означало, что курьер доставки еды прибавочную стоимость создаёт, а таксист, когда везёт вас из гостей - нет.
Огромный примат интересов государства в бухгалтерии это все таки наш местный перекос. Некоторые считают что фин-отдел это вот кошелек генерального и не больше.
Тут вообще какая-то каша, на мой взгляд. Есть учёт. Есть государство, которое его регулирует - потому, что всех подозревает в том, что они хотят незаплатить налогов. Есть бухгалтерия, а есть финотдел, который шире, чем бухгалтерия.
Бухучет в том или ином виде позволяет делать срезы структуры активов/пассивов во времени, т.е. иметь полную информацию для управления производственным процессом, только что это в какой то момент стало не модным.
Можно, но это уже аналитика поверх бухучёта. С которой работают экономисты, а не бухгалтеры.
"Примат интересов государства" выражает в том, что синтетический учёт (исключительно в денежном выражении который) обязателен, а аналитический - опционален. Впрочем, аналитический учёт еще и геморроен, так что часто проще какой-нибудь складской учёт в чём-то своём вести, заточенным под производственников, а не бухгалтеров, проинтегрировав при необходимости с бухучётом.
Бухгалтер вообще не полезет оценивать кучу песка - это не его зона ответственности.
Прошу прощения, вы не правы, вопрос каким способом оценить кучу песка был одним из дополнительных вопросов защиты дипломной по бух. учету моего буха, который и определил его цвет ближе к инфракрасному.
Емнип, я память моя может мне и изменить, определение методов и стандартов внутренней документации это тоже классические задачи бухучета.
Да и как же не его зона ответственности когда при смене
главбуха должна быть инвентаризация активов, опять же емнип, зачем на главбуха вешают матответственность?
" а там никаких "5% на ошибки оператора" не предусмотрено "
там не предусмотрено, а в жизни предусмотрено. Чекрыжат ровно с той целью. Я когда-то автоматизировал ввод показателей и выслушал чудную лекцию о статистических ошибках операторской работы, закладываемых в системы учета, об статистически ошибках автоматических систем учета и методологиях их уменьшения. Игнорирование природы исполнителя это ошибка построения учета. Водителям вот законодательно запрещают находиться за рулем больше положенного. Законодательно ограничивают максимальные скоростя, существуют нормы организации рабочего места и т.д. Можно закабалить человека как угодно, но никакой существенной прибыли это не принесет, а проблем добавит существенно.
Есть бухгалтерия, а есть финотдел, который шире, чем бухгалтерия.
Где то шире, а где то уже - давайте найдем устоявшиеся определения. Финотделу к примеру обычно на амортизацию основных средств пофиг до момента, пока отделы в план бюджета не внесут покупку нового или кап. ремонт. На учет и переоценку нематериальных активов обычно финотделу глубоко фиолетово. Операционная деятельность, деньги в моменте ради денег.
что синтетический учёт (исключительно в денежном выражении который) обязателен, а аналитический - опционален
Синтетический это по форме верно, а по факту издевательство. Раскручивать цепочки взаимосвязанных хозопераций без аналитики настолько трудозатратно, что практически бессмысленно.
=========================================
Но это я утрирую, конечно, я одинаково уважительноотношусь и к фин. и к бух. учету, поэтому предпочитаю их не особо разделять, а если разделять то по потребителям информации и их запросам. Я сам из точных наук и мне симпатична аналогия представлением активов/пассивов предприятия как вектора и его матричных преобразований во времени для достижения итогового вектора активов как результата. Соответственно задача дробится на систему ввода данных в модель, сама математика преобразования векторов, система управления (по факту постановки задач на исполнение и организацию стопоров для автоматических "исполенний статей бюджета", у меня "исполнение статьи бюджета" это процесс преобразования активов) и систему поиска максимумов.
Прошу прощения, вы не правы, вопрос каким способом оценить кучу песка был одним из дополнительных вопросов защиты дипломной по бух. учету моего буха, который и определил его цвет ближе к инфракрасному.
Ну вы еще предложите ему самому это вёдрами на весы таскать...
План действий примерно такой:
берётся МОЛ (материально ответственное лицо)
берётся комиссия по инвентаризации
в комиссию обязательно включается кто-то из высшего руководства
комиссии предлагается выбрать из "методички" устраивающий её метод. Хотят - "геодезический", хотят - взвешивают, хотят - плотность берут по справочнику, хотят - проводят контрольное взвешивание для определения плотности.
Комиссия, в зависимости от степени ссыкотности для себя и для МОЛ, проводит измерения и расчёты, бухгалтер их проверяет, и принимает акт.
По ходу работы, в зависимости от того, выявлена недостача или излишек, у членов комиссии сам усиливается процесс вспоминания школьных знаний и желание произвести измерение более точными методами.
Поэтому, повторяю - непосредственно процесс измерения кучи песка - не задача бухгалтера, его задача - при этом поприсутствовать )
Емнип, я память моя может мне и изменить, определение методов и стандартов внутренней документации это тоже классические задачи бухучета.
Только в тех случаях, когда это требуется законодательством, регулирующим бухучёт и налогообложение.
Да и как же не его зона ответственности когда при смене
главбуха должна быть инвентаризация активов, опять же емнип, зачем на главбуха вешают матответственность?
Вот и мне интересно, зачем он дурак это на себя повесил, а не на МОЛ, который непосредственно заведует местом хранения этой кучи песка, или другое лицо матответственное в силу закона (главбух не один "в силу закона", но из бухов в силу закона - только один "глав")?
там не предусмотрено, а в жизни предусмотрено. Чекрыжат ровно с той целью. Я когда-то автоматизировал ввод показателей и выслушал чудную лекцию о статистических ошибках операторской работы, закладываемых в системы учета, об статистически ошибках автоматических систем учета и методологиях их уменьшения.
Кажется, мы о разных вещах всё-таки.
Для учёта денег - усушки, утруски и иных 5% не предусмотрено.
А если вы говорите об аналитическом учёте, то "усушку и утруску" я прямо упоминал. Там есть определённое нормирование (законодательное или локальными нормативными актами) для ценностей, измеряемых не в штуках. А вот со штуками уже ой, только локальным НПА или доброй волей руководителя.
Но это - проблема МОЛ, а не бухгалтера, если, конечно, бухгалтер не дурак и не взвалил всё на себя. А если дурак и взвалил на себя работу кассира, курьера, продавца и кладовщика - ну ССЗБ. Лучше бы на руководителя организации это повесил - а тот бы уже организовал соответствующий процесс среди работников сам.
Где то шире, а где то уже - давайте найдем устоявшиеся определения.
Так и бухгалтерия - понятие широкое. Там может быть материальный отдел, расчётный отдел...
Бухгалтер может быть еще и кадровиком в СМБ. А HR может быть и отдельной службой.
Бухгалтерия может быть подразделением финансовой службы, а могут быть и разными службами.
Синтетический это по форме верно, а по факту издевательство.
Смотря для чего и для кого. Для СМБ - может и хватить с необходимым минимумом типа учёта ОС и склада - да и то в силу требований закона потому что надо. Для крупной организации - да, аналитический учёт важен и нужен.
Но это я утрирую, конечно
Ну тогда надо уточнять, о какой модели "сферического бухгалтера в жидком вакууме" идёт речь.
А то я тоже утрирую, но в другую сторону :)
Вообще предложение такое: давайте рассматривать государство, как арендодателя.
Поясню. Если вы к примеру дистрибьюторская сеть, то производители продукции налагают на вас кучу аналитики по их товару. Продаваемость, остатки, частоту сколько спрашивают и там бог весь еще что. Вам лично оно для развоза товара не надо, а производителю надо и Вы вынуждены собирать эту информацию что бы работать с товаром производителя.
То же при аренде где договор аренды может накладывать ограничения на деятельность в помещении, условно что не запрещенкой там барыжите.
Так вот государство, для разрешения ведения деятельности на его территории требует предоставлять некую информацию - статистическо-экономического характера в каком то виде, который оно может воспинять.
Вот при построении системы учета на предриятии мы, как арендатор услуг государства, вынуждены учитывать и его интересы в информации.
Вот, вам еще и поле понадобилось...
Зато дебет/кредит пропали.
Вот, вы начинаете интерпретировать на уровне учёта к тому же...
Я не интерпретирую, я просто правил игры не знаю. Ну и если про отчетность забыть, а попытаться посмотреть на запросы начальства, так все равно, чтобы график зависимости количества денег от времени построить, все равно нужно все денежные потоки с нужным знаком просуммировать и кумулятивную сумму посчитать.
прикол в том, что кумулятивная сумма равна нулю.
прикол в том, что кумулятивная сумма равна нулю.
Да ну как же? Вот касса (или несколько) , вот денежные потоки. Приход плюс, уход минус. По времени отсортировали, пошли сумммировать. Ноль - только если сколько заработали, столько и потратили.
А долги? А основные средства? А активы, в том числе нематериальные? Да и деньги на кассе есть, только они не ваши. А бывает хуже, прибыли вагон, а денег нет.
И вот когда будете своить уже все это, будет очень хотеться что бы сумма была все таки ноль итоговая, потому что это показатель.
Собственно в классической двойной записи две основных магии, одна из них следствие закона сохранения актива - кредит равен дебету, а вторая это счета финансового результата, уже чистая математика, о которых в основном умалчивают. Но без второго первое не обладает полнотой.
прикол в том, что кумулятивная сумма равна нулю.
Да ну как же?
Ну вот так. Если не ноль - значит, где-то напортачили, и надо пересматривать все 100500 проводок, чтобы понять, где именно.
Недостаток один - не все виды ошибок таким образом выявляются. Иначе бы, например, никогда инвентаризации не требовались бы.
Зато дебет/кредит пропали.
Одно убрали, другое добавили - а смыл?.. Опять же, еще раз обращаю внимание - бухгалтер не работает с БД. Он работает с проводками. Как будете их хранить в БД - его вообще не волнует. Да хоть в блокчейне хранить - что, кстати, будет близко к оригинальной концепции ведения гроссбухов, сшитых, опечатанных и пронумерованных по листам.
Буху надо, чтобы отображаемая и печатаемая информация по каждой операции сходилась с первичкой.
Ну и если про отчетность забыть, а попытаться посмотреть на запросы начальства, так все равно, чтобы график зависимости количества денег от времени построить, все равно нужно все денежные потоки с нужным знаком просуммировать и кумулятивную сумму посчитать.
Для этого уже посчитались сальдо по счетам, осталось поверх всего этого наложить аналитику и нарисовать графики. Но это уже аналитика, а не учёт. И потому для экономиста, а не для бухгалтера.
Бухгалтерия стала совершенно не нужна с появлением компьютеров и реляционных баз данных
Бухгалтерия это прежде всего стандарты учета. Чтобы взяли какую-то сущность - и у всех она обозначала одинаковое. Без этого у вас будет зоопарк терминов, уникальных для каждой системы. Вы даже сравнить 2 фирмы между собой по ним не сможете - ценность этих данных будет нулевая для всех, в том числе и для налоговой.
Причем тут бумажный носитель? Как компьютер и реляционная база данных убережет вас от ошибок? Как она без системы позволит вести учет по жестким правилам? Бхгалтерская методология имеет самую главную гарантию, что ничего не возникает ниоткуда и не девается никуда, как вы это обеспечете без нее?
Опять же, вы не поверите но та же 1С по крайней мере с 7.5 (ниже не работал) использует для хранения реляционную базу данных.
Бухгалтерская методология имеет самую главную гарантию, что ничего не возникает ниоткуда и не девается никуда
Как считаете, Озон и Почта России тоже используют бухгалтерскую методологию, чтобы отслеживать товар на складе? Или нет?
Мне реально непонятно. Вот я вношу все события в БД. Увезли товар со склада - вставил строку в БД. Поступили деньги на счет вставил строку в БД. В базе у меня актуальное состояние и счета и склада. Можно сверить и все совпадет. Зачем мне бухгалтерская методология?
Допустим, сотрудник захочет сфальсифицировать данные. Ничто не мешает ему вставить ложные данные хоть в мою БД, хоть в бухгалтерскую с двумя записями. Тут методология не защитит.
Другой пример. Товар товар увезли со склада, но забыли внести в БД. А деньги на счет пришли. И непонятно, за что. На самом деле, понятно - номер счета же есть. И можно по связям документов найти, где забыли записать. В бухгалтерской системе наверное, вручную это будет проще сделать. Но мне не нужно вручную, у меня есть компьютер. Весь огород только ради этого?
Увезли товар со склада - вставил строку в БД. Поступили деньги на счет вставил строку в БД. В базе у меня актуальное состояние и счета и склада. Можно сверить и все совпадет. Зачем мне бухгалтерская методология?
Если пользоваться той же логикой, как мне в примерах с "деньги отправили караваном", объясняли, то на самом деле тут бухгалтерская методология есть.
Потому что поступили деньги от кого-то (записываем же это? Чтобы знать, кому товар должны были/стали) или увезли товар кому-то (тоже ведь записываем? Чтобы знать, кто его оплатил/получил (чтобы он еще раз не пришел и не спросил "а где мой товар?")
Похоже на какой-то костыль. Сейчас на любой чих должен быть документ (накладная, счет-фактура, договор, и т.д) в котором вся информация есть, известны связи между документами и событиями, и эти документы лежат тут же в БД.
И как Вы по этим документам узнаете COGS?
И как Вы по этим документам узнаете COGS?
Сосчитает по этим первичным документам нужную сумму, что ему сейчас интересна. Если документы достаточно полные - должно получиться.
Стоит ли таким заниматься, когда все вокруг делают эээ... ну пусть будет materialized view в виде бухгалтерского учета - а кто его знает. Скорее всего не стоит.
Так в указанных документах нет этой информации вообще. Что считать собрались?
Так в указанных документах нет этой информации вообще. Что считать собрались?
Я так понял, что аргумент был, что документы достаточно подробные и их много разных, а не только те, что были перечислены.
Если документов достаточно, чтобы учет вести, то вроде бы чисто теоретически его можно и не вести, а по требованию все эти записи считать.
Вот только осмысленность этого неведения - сильно сомнительна.
Это хороший вопрос - как посчитать очередной упоротый отчет, завязанный на представление данных в бухгалтерском виде.
Будет непросто, как и вообще с любыми отчетами, но, как уже заметили, при наличии полных исходных данных, всё реализуемо.
Вы упрощаете роль бухгалтера.
Бухгалтер это тот кто собирает первичную документацию, заносит ее в базу, следит за ее корректностью, устраивает разборки с налоговой и пфр в случае ошибок, решает как оптимизировать налоги.
Основная работа бухгалтера это решение разных задач - заставить работника принести документ, разобраться с налоговой которая начислила лишние налоги, доказать правоту организации, объяснить проблему юристу и руководителю.
Только далекие от темы люди считают что работу бухгалтера можно переложить на компьютер.
Директор сказал компьютеру - разберись почему там дофига налогов насчитали, и он побежал разбираться.
Легко переписать программу и переучить компьютер. Сложно — привычки и людей.
Как баланс сможете нормально свести так и приходите. Я это видел множество раз. Типа мы щас движком БД посчитаем. А потом балансы не сходятся, копейки теряются. Деньги в float кладут как и балансы и куча других радостей и глупостей.
Не хочется "раскручивать вентилятор", но чистое любопытство... Вопрос к топикстартеру: а зарплату в его организации на чем считают? а отчеты его бухгалтерия из какой программы сдает? Вот интересно, чтобы рассказывал "современный разработчик" в налоговой если бы секта "соблюдателей ритуалов" перестала поддерживать "изменения действующего российского законодательства"? Понимаю, что этому холивару не будет конца, но не люблю такие "однозначные экспертные заключения".
Могу ответить серьёзно, без иронии.
Я живу не в России, но у меня был довольно плотный опыт с бухгалтерией. Давным-давно я писал бухгалтерскую систему для финуправления одного региона с 24 муниципалитетами (у нас это называется сакребуло). Проект был полностью авторским — всё разрабатывал сам: интерфейс, база, отчётность.
В начале провёл анализ — на чём писать и как всё организовать. В языках программирования тогда был полиглотом, и от 1С отказался моментально. Понравилась связка Delphi + SQL, где под SQL можно было подключить любую базу: от Oracle до Firebird — полная свобода выбора.
Для отчётов использовал Excel (если не ошибаюсь, компонент FastReport). Шаблоны оформлял настолько аккуратно, что даже банк, куда сдавались отчёты от финотдела, взял наши шаблоны за основу — сказали, лучше не придумаешь. Было приятно.
Система поддерживала любую базу данных, имела веб-интерфейс и позволяла удалённое администрирование. Работала стабильно, как часы.
А самое приятное — за этот заказ я смог позволить себе купить машину. Это был мой единственный крупный проект, связанный с бухгалтерией, но он оставил хорошие воспоминания.
Так что я понимаю обе стороны: и тех, кто пишет эти системы, и тех, кто с ними работает каждый день.
Ого, какой у Вас опыт! 👏🏻
Вы это в другой стране делали, не в России?
По моему глубокому убеждению 1С выживает именно оттого, что имеет связи с налоговой. Вы утверждаете, что даже срощено с ней? Готова поверить. Потому что формы государственной отчетности зачем-то каждый год меняются, хотя бы в одной клеточке какие-то другие буквы должны быть написаны, даже когда смысла в этих изменениях нет. Если у тебя самописная программа, нужно эти формы всё время менять, ну и под изменения в законодательстве подстраивать - любую самописную программу нужно постоянно поддерживать программисту, а вот 1С как будто даёт свободу от программиста - ставь обновление, один программист 1С пропал, другого найдёшь - полный рынок таких программистов, у предпринимателя создаётся впечатление, что 1С - это гибко и надёжно, и он даже готов за это даже переплачивать... Хотя ему говорят, что это даже дешевле вдобавок. А уж как на самом деле - переплатил он или нет, он никогда не узнает 🤷🏼♀️
Да, вы очень точно всё описали. Именно поэтому я когда-то отказался от 1С, когда писал бухгалтерскую систему для финуправления. Сразу почувствовал, что это не просто программа, а инструмент зависимости, навязываемый сверху. Постоянные изменения форм, обновления, жёсткая привязка к налоговой — это настоящая "игла", на которую сажают разработчиков и бухгалтеров.
Я по натуре анархист и не люблю, когда кто-то диктует, как мне работать. Мне ближе полная свобода — Мать Анархии! Поэтому я выбрал путь самописной системы: SQL, Delphi, отчёты в Excel — всё было под моим контролем, никакой внешней зависимости. Это был тяжёлый, но честный путь. С тех пор уверен: лучше быть хозяином системы, чем её заложником.
P.S. Ваш выбор уважаю — в вашей ситуации, увы, просто нет реальной альтернативы.
Как хозяин системы, вы постоянно переделывали её по требованиям налоговой? Или вы решили не выполнять требования налоговой?
Мы были налоговой. Мы налоговой зарплату платили.
Дальше — хуже. Пошли слухи: нужно делать базу данных выборов, перед самой цветной революцией. Но нас туда не пустили. Приехала команда специалистов из США — отдельная группа. И что странно — писали они всё под Windows, на Microsoft SQL Server. Меня поразила чёткость работы их программ. Но там всё было сертифицировано — от специалистов до самих программ. (Там 1С даже не пахло, дела сурьезные)
Вот такие дела.
Сейчас я — нищий программист. Остались лишь воспоминания... Иногда пишу статьи — о чём можно писать.
Поэтому я выбрал путь самописной системы: SQL, Delphi, отчёты в Excel
Если бы вас заставили на это всё покупать лицензии - вы тут же перешли бы на 1С :)
Вы забываете что работа бухгалтерии с налоговой - это только малая часть ее функций. На самом деле, даже для небольшой конторы, что-то производящей все сложнее.
Есть материалы и склад - нужно закупать, учитывать, выводит со склада под проведенные работы.
Есть работники. Часть которых сидит на окладе, часть на сделке. Нужно учитывать кто сколько сделал.
Есть работы - договор, акт сдачи-приемки и т.п. В каждой работе задействованы работники (и им надо заплатить каждому по мере его участия), задействованы какие-то материалы, которые нужно закупить на склад, потом вывести со склада под конкретную работу.
И все это (кадры, склад, договоры и акты выполненных работ) нужно свести воедино чтобы потом посчитать зарплату, отчитаться перед налоговой и т.п.
И не забывать что каждая операция подтверждается конкретным документом (первичная документация).
И никогда не бывает все идеально - есть разрывы по подписаниям акта приемки и выплатой денег и т.п. В реальной жизни там много тонкостей и "гибкостей".
А отчеты для налоговой - это самая простая часть всего этого.
Сам опыта не имел, но товарищ по прошлой работе всем этим занимался. Именно в таком вот объеме - кадры, склад, договора подряда, акты выполненных работ, налоговая. В рамках одной отдельно взятой конторы. И да, Delphi + SQL + FireBird. В архитектуре клиент-сервер. Т.е. был сервер и набор тонких клиентов для каждого конкретного рабочего места.
Вы забыли добавить, что предприятие хочет знать, прибыльно ли оно работает, а для этого нужно считать прибыль, а для расчета прибыли - себестоимость. А для кредитования, например, нужно знать активы, которыми предприятие располагает. И т.д.
Я много чего забыл :-) Потому что не спец, просто "мимокрокодил". Видел все это со стороны, хоть и достаточно близко.
В частности, когда заключается договор подряда, сумма его должна быть обоснована. Для этого существует специальный софт для составления смет. Та же Гранд-Смета была. И он должен стыковаться с основной системой...
Я когда работу менял, чуть не попал в контору, где нужно было писать плагины к какой-то систем архитектурного проектирования чтобы увязывать стоимость сметы проекта с 1С...
Так что в целом тут как в банке - не просто счета-проводки, но еще куча всего со всех сторон если начинаешь вникать.
Да по фиг ФНС на 1С. У ФНС есть ГНИВЦ с двумя тысячами сотрудников, которых надо загрузить работой за бюджетные средства. Ведь любое изменение нормативки - это так же изменение в информационной системе ФНС.
1С просто обладает наибольшей клиентской базой, что позволяет окупать беспрерывную разработку модификаций незначительными для каждого клиентами суммами за поддержку.
Все это хорошо работает пока законодатель не меняет требования к учету с скоростью печати на современном бешеном принтере.
Расскажите, пожалуйста, как вы обеспечили быстрый ответ на изменения в бухучёте?
Вот вы построили форму, а через два месяца надо другую. На следующий год её вообще не надо, а вместо неё нужен другой расчёт. Ещё через полгода стали нужны новые обязательные поля.
Как ваша программа помогала всё это сделать?
Не везде изменения появляются по 100500 в наносек, где то годами ничего не меняется. В России увы не катит.
Приведите пожалуйста примеры изменения ПБУ/ФСБУ каждые 100500 наносек.
И пожалуйста не пытайтесь выдавать изменения в оперативном (пример: обязательная работа с системой "Честный знак") и налоговом учетах (пример: НДС при упрощенной системе налогообложения) за изменения в бухгалтерском учете.
Изменение НДФЛ с 2025, изменение НДС для УСН, это только то, что появилось совсем недавно. О том с какой скоростью штампуются новые формы одних и тех же отчетов лучше умолчать (
И я не понял, а изменения не ПБУ не требуют изменения учетного софта?
Изменение НДФЛ с 2025, изменение НДС для УСН, это только то, что появилось совсем недавно. О том с какой скоростью штампуются новые формы одних и тех же отчетов лучше умолчать (
Вот сейчас Вы выдаете изменения в налоговом учете за изменения в бухгалтерском. В бухучете все осталось по-преженему: "Дт.70-Кт.68 СуммаНДФЛ", "Дт.90-Кт.68 СуммаНДС".
И не надо все валить на "бешенный принтер": изменения были приняты и опубликованы на всеобщее обозрение в июле прошлого года, разъяснения ФНС по новому порядку учета НДС в 2025 году были выпущены уже в августе 2024 (по НДФЛ – к началу октября 2024) – у ERP-писателей (1С, Галактики и т.п.) было минимум 3 календарных месяцев на подготовку релиза.
И я не понял, а изменения не ПБУ не требуют изменения учетного софта?
Требуют. Вопрос был в том: с какой скоростью меняются ПБУ (подсказка: посмотрите когда был принят действующий ныне стандарт по бухгалтерскому учету основных средств и какое время действовал его предшественник).
Программа и база были невероятно гибкими. Осталась одна обученная студентка — она делала любые отчёты, вплоть до самых нестандартных. Начальник говорил: "Сделай мне отчёт вот такой, с такой-то зависимостью", — и через 20 минут всё было у него на бумаге и в Excel. И при этом — ничего сложного! Это вам не 1С.
РС Студенка была симатишной и умницей! Что редкость!
В России, пока бы вы эту систему написали она уже бы 100 раз устарела.
И в одиночку, без группы методистов вы бы никогда не реализовали расчет зарплаты больше чем на 10 человек с поддержкой всего объема трудового и зарплатного законодательства.
А 10 форм для банков слепить каждый формошлеп сможет
У нас навалом таких систем было. Лет 25 назад. Не знаю, есть ли сейчас самописные или нет, со временем всех выдавила 1с. Главный плюс 1с - стандарт, плохой или хороший, но стандарт. Ну а про главный минус самописных систем знают все - есть разработчик, система работает. Нет разработчика, система не работает. И все, суши весла.
А коллега рассказывал как работал несколько месяцев с подобной системой для сети магазинов, написана на Delphi, разработчик уволился. Это была боль и страдание. Версия Delphi и БД были устаревшие, доработки шли медленно, легко было всё уронить, так как многие моменты автор в голове держал, документации нет особо. Потом перешел в SAP/1C в крупную компанию и уже не жаловался.
С любой БД? Прям настоящее покрытие нагрузочными тестами или просто любой БД, утверждающей, что поддерживает SQL-92 и к которой есть драйвер?
И сколько стоила поддержка Вашего продукта, его расширение? Сколько спецов в стране было? Какой порог входа, почему экономически все эти спецы не перебежали хлеб с маслом во внедрении и поддержке Вашего продукта?
Какой вообще потенциал Вашего движка для эволюционного развития вместе с предприятием? Потенциал по интеграциям?
И кто знает это продукт?) А 1С Бухгалтерия знают все)
Сектанты 1С - Кто это? Нет, буквально, кто? Те кто кричат на каждом углу что это идеал который лучше быть не может? А такие прям точно есть? Прям в достаточном количестве что бы это было проблемой?
1) Если я наемный рабочий который его использует потому что мне так сказал мой начальник - я сектант?
2) Если я обучаю ему потому то есть спрос и я на этом зарабатываю - я сектант?
3) Если я владелец компании которой дешевле и удобнее всего использовать 1С - я сектант?
Претензия в том что гос. структуры его проталкивают? Если так и происходит то я уверен что люди которые так делают явно опираются не на сектанство, по крайней мере не на сектанство по 1С. У них там своя геополитика и 4D шахматы в голове, фигурально выражаясь - Так что места для анализа какие там преимущества и вред от 1С в их черепной коробке нет и быть не может.
Откажитесь от 1С во славу великой оптимизации и всеобщего блага !! - Ну то есть мне отказаться от работы ? Или перестроить бизнес на что-то другое в ущерб своей компании? Или пойти воевать с государством которое это навязывает? ...в россии...в россии 2025 года. А не пойти ли тебе...гхм, я хотел сказать что это - крайне опрометчивые призывы.
В целом же статья интересная, если бы без проповедования и с большим количеством материала, была бы вообще отличной.
1С не стоит на месте) они куда но движутся - есть(в разработке я так понимаю) 1С элемент - можно даже пощупать и там все почти ( или так кажется) по взрослому - и типы, и автокомпилит, и ООП и отладка, и ide ( облачная ) но почти vscode - с темными темами и прочим ...
Программное чудовище, которое не должно было выжить или Что такое 1С на самом деле и зачем оно было создано
За последние 30 лет 1С пережила столько «религиозных» войн между ее сторонниками и противниками, было выложено такое количество «железобетонных» аргументов «за» и «против», что статья автора, кажется, на этом фоне, «детским лепетом на лужайке».
Более интересны тайные мотивы автора в написании статьи. Ведь, если система морально устарела и стала безнадежной, то она уйдет тихо, сама собой и гнать ее нет никакой необходимости. А если есть, то ради продвижения другой системы. Разве не так? Ибо «лучшее – враг хорошего». Т.е., если есть лучшее, то почему вы переживаете за хорошее?
Проблема то в том, что однозначно «лучшего» в системах учета как-то и не видно, особенно, в соотношении цена / качество.
Я бы даже сказал крамольную мысль: «Семерка» (платформа 1С77) это была лучшая система разработки собственных бизнес приложений, например, для специализированного расчета заработной платы и учета рабочего времени на средних производственных предприятиях. Особенно, в соотношении цена / качество.
Я лично, являюсь автором подобной системы на одном из предприятий. И она меня кормила двадцать лет и еще бы столько же, если бы наша фирма не была бы поглощена более крупным предприятием, где имеются свои умельцы с собственной «зарплатой» (системой учета), основанной, правда, на веб-технологиях (просто потому, что это огромный конгломерат различных подразделений). Я бы тоже разрабатывал распределенные системы учета, если бы была такая потребность. Но наша фирма, много лет, была самостоятельной структурой.
Но, даже они вынуждены, с этого года, переходить на «восьмерку» (1С8х) (не знаю, почему, поскольку там уже не работаю).
1С8х, я лично, тоже недолюбливаю, по причине ее избыточной громоздкости и явно намеренного переусложнения, в части технологии разработки. Т.е., ее уже делали ради максимального извлечения прибыли фирмой «1С». Тем не менее, если бы, сейчас, у меня возникла возможность делать карьеру на «восьмерке», то я бы не отказался. Просто, кто хочет – ищет возможности, а кто не хочет – причины.
P.S. Как ни относись к «1С», но она всегда действовала по принципу: «А Васька слушает, да ест»
Ведь, если система морально устарела и стала безнадежной, то она уйдет тихо, сама собой и гнать ее нет никакой необходимости.
А она и уходит: лет 15 назад без 1С даже мелкий предприниматель жить не мог, а теперь почти все банки напрямую подобную функциональность предоставляют, достаточную для ведения дел обычным ООО "Вектор" и ИП Иванов
А она и уходит: лет 15 назад без 1С даже мелкий предприниматель жить не мог, а теперь почти все банки напрямую подобную функциональность предоставляют, достаточную для ведения дел обычным ООО "Вектор" и ИП Иванов
Вы смотрите на 1С с точки зрения «мелкого предпринимателя», а я с точки зрения среднего автономного производственного предприятия (порядка тысячи сотрудников). В котором, например, довольно сложная система учета и расчета заработной платы. Покупать при этом 1С:ЗУП (который еще надо серьезно допиливать по части алгоритмов и отчетов), дорогой сервер иди сервера, и нести прочие расходы по внедрению и обслуживаю, как бы, не слишком разумно, во всяком случае, пока. Особенно, если есть уже проверенная годами «семерка», которая в связке в дешевым движком Visual FoxPro и терминальными сессиями на старом дешевом сервере (с двумя гектарами оперативной памяти) поддерживает, без напряга, до двадцати клиентов на 1С77.
Все работает как часы, включая учет рабочего времени сотрудников (по персональным картам доступа). Отчетность в внешним миром налажена, в т.ч., на уровне клиент-банков (прямая поддержка зарплатных проектов и прочее).
И тут приходите вы и говорите: «Не, не, всё устарело! Переходим на другую систему!». Ну, если у вас лишние миллионы есть, энергию девать некуда, но можно все поломать и что-то строить заново. Или, как в моем случае, пришла новая фирма, которая нас поглотила, в свой конгломерат предприятий. Естественно, у них уже есть своя отлаженная система учета. Они только попросили у меня все данные, на «блюдечке с голубой каёмочкой» и загрузили их в свою систему. Что как бы не большая проблема. Я тоже мог бы подключить к своей системе новое предприятие, с готовыми данными, без особых усилий. А для увеличения производительности нужно только обновить свой старый сервер, хотя бы в части увеличения памяти (которую уже невозможно купить из-за ее древности).
Понятно, что моя система учета им стала уже не нужна, поэтому я был вынужден уволиться, поскольку всю мою работу у меня забрали. Тем не менее, эта, распределенная по большой территории, компания, почему-то, переходит со своей системы учета (основанной на веб-технологиях) на «восьмерку». Смысл, видимо в том, что их система не всё «тянет», поэтому переход на 1С83 здесь достаточно уместен, хотя и дорог, с учетом всех нюансов.
В итоге получается, что «советы посторонних» как бы не сильно нужны. Куда переходить, на что переходить, что лучше, что хуже? Думаю, мы и сами как-нибудь разберемся…
Как-раз лет 15 назад у таких больших компаний была популярна SAP, ну может еще чуть более крупных. Вероятно по настоянию менеджеров, которым чем дороже, тем лучше по понятной причине. Сам наблюдал несколько случаев, как в 2007-2010 году сносили самописную работующий систему и внедряли SAP. А сейчас идет обратный пример, переходят с SAP на 1С.
Как-раз лет 15 назад у таких больших компаний была популярна SAP
Была еще тогда:
«Microsoft Dynamics NAV — интегрированная система управления предприятием (англ. Integrated Business Management Solution) для среднего и малого бизнеса, поставляемая компанией Microsoft в линейке продуктов Microsoft Dynamics, объединяющих бизнес-решения ERP (англ. Enterprise Resource Planning, Планирование ресурсов предприятия) и CRM (англ. Customer Relationship Management, Система управления взаимоотношениями с клиентами).»
Сначала пытался использовать ее для написания своей «зарплаты». Но она оказалась слишком уж заточенной на защиту, непонятно кого от кого. Т.е., работать с ней было крайне неудобно. А вот «семерка» – самое то! Легкая, неприхотливая, дешевая. В умелых руках может делать чудеса. Поэтому, все, кто трындит о ее, якобы «отстойности», ничего лучшего в соотношении цена / качество / скорость разработки, предложить ничего не могут до сих пор.
1С77 да и вся линейка 1С дискредитирована, в основном, своими типовыми конфигурациями, авторы которых всегда делали их по принципу: «Нам с ними не работать!». Поэтому, если всю конфигурацию ваяешь, с нуля сам, то вполне можно получить конфетку, как это было у меня, что кормило меня целых двадцать лет! И еще столько бы, если бы не форс-мажор.
Мои друзья программисты, которые решали аналогичные задачи, но в другой фирме, использовали для этих целей MS Access-97 + VBA + MSDE / SQL-server. Они (очень крутые программисты) работали над этим вдвоем, а я один. А результаты у нас были примерно одинаковыми, правда, задачи у них были более специфическими. А вот более новые версии MS Access они недолюбливали, как и я «восьмерку». И подобное можно сказать про многие современные программы. Тенденция, однако… :)
А сейчас идет обратный пример, переходят с SAP на 1С.
А что делать? Хорошо бы, если бы у фирмы «1С» появился бы достойный внутренний конкурент, но, почему-то, другие продукты не «взлетают», хотя они, в природе, есть, даже опенсорсные.
Ровно до тех пор пока Государство лояльно к мелким предпринимателям.
А если случится катаклизм вроде того, что назревает сейчас в Казахстане (Новый Налоговый Кодекс) - тут-то и кирдык всем этим системам от банков.
И тут на сцену опять выходит 1С со своей Базовой Бухгалтерией ценой в 6000 рублей с пожизненными бесплатными обновлениями. Или облачная - ценою в 500-800 рублей в месяц за рабочее место.
Ибо ни один банк быстро не справится с таким кардинальным изменением в законодатеьстве.
статья автора, кажется, на этом фоне, «детским лепетом на лужайке».
Так и есть!
Для бухгалтера проще выучить 10 команд 1С, чем осваивать PostgreSQL, Python и нормальный UI
Это, пожалуй, самое шедевральное! Бухгалтер, осваивающий pgsql и python. Хорошо демонстрирует максимализм и оторванность от реальности.
pgsql и python
Если бы еще и айтишники занимались делом, а не этими благоглупостями, цены бы им не было
Книга, по которой я учил SQL, — «Руководство по реляционной СУБД DВ2» К. Дейта. И да, там написано, что SQL создавался именно как язык конечного пользователя. Ну а потом началось — менюшки, окошки, кнопочки и вот это всё...
Да, это обычное явление. Сюда же можно отнести nocode/lowcode платформы, и в стеке 1с тоже была попытка захода "любой бухгалтер сможет себе напрограммировать". Все это заканчивается одинаково: для результата в 10к записей это работает (условно это уровень экселя с ВПР()). А выше 10к записей это проще выкинуть и написать через хорошего разработчика.
Думаю потому, что при упрощении языка для обычного пользователя мы очень быстро теряем оптимизации, приходя к алгоритмам n^2 на каждом шаге, теряем оптимизации, уменьшающие сложность на большом проекте - и где-то только в конце этого пути уровень сложности падает ниже границы для использования обычным пользователем.
В сущности человечество хочет каждый раз через простоту ценой производительности вовлечь новых людей, но потом оказывается, что оперировать бОльшим объемом данных выгоднее для конечного бизнеса, чем ждать каких-то высот от подхода "простота ценой производительности" (=> вовлечение больших масс людей => низкие цены) .
SQL создавался именно как язык конечного пользователя
Как и COBOL примерно в ту же эпоху (кстати, в нем вставки SQL выглядят как родные). Но с тех пор понятие конечного пользователя сильно размылось. 1С ведь тоже был изначально заточен под то, чтобы быть понятным бухгалтеру.
SQL создавался именно как язык конечного пользователя.
А когда-то мы смеялись про объявление "требуется программист для работы с программой Word"...
Вообще это наследие теперь уже де-факто устаревшей парадигмы, что для работы с компьютером все должны учить "компьютерный язык".
Из-за которой мы даже в 90-е вошли с тем, что "оператор ЭВМ" был отдельной профессией, которая записывалась в трудовую книжку (а "системного администратора" официально не было - коммерсы могли в трудовую писать что угодно, хоть и.о. царя, а вот госы - уже нет). Да и поныне эта профессия официально не померла. А ведь по сути эта "профессия" - прокладка между компьютером и специалистом в предметной области, не умеющим пользоваться компьютером...
Так что да, на заре информатизации не задумались, что "просто пользоваться" компьютером можно без "языка", а через пользовательский интерфейс. А оно вон как оказалось - даже CLI "слишкам сложна", всё работает через окошки, менюшки, кнопки, иконки и "вот это всё"...
Я может чего не понимаю конечно в вашей мысли.
Но что это за специалист и в какой предметной области который умея "пользоваться компьютером" настроит самостоятельно, например, почтовый сервер или сервер БД?
Я может чего не понимаю конечно в вашей мысли.
О да, без знания некоторых тонкостей можно не прочувствовать всю "глубину" ситуации.
Хотя, намёк-то я оставил достаточно толстый - коммерческие организации проблемой "как назвать должность" затронуты не были, это была проблема именно госструктур.
Всё потому, что они были обязаны (да и сейчас тоже не совсем чтобы вольница) использовать классификатор профессий и должностей, заниматься самодеятельностью - грех, харам и преступление в одном флаконе, а в классификаторе были предусмотрены "инженер-программист", "инженер-электроник", "оператор ЭВМ", а вот "системного администратора" - не было.
С тех пор классификаторы конечно расплодились и несколько актуализировались, но всё равно - если у вас должность "на острие прогресса", а бюрократы не успели это внести в классификатор, а работодатель обязан ему следовать - "будет забавно".
Но что это за специалист и в какой предметной области который умея "пользоваться компьютером" настроит самостоятельно, например, почтовый сервер или сервер БД?
Ну вот так и жили... В трудовой "пишем инженер-программист, системный администратор на ум пошел".
🙃
Вы правы в конечном абзаце - это всего лишь рефлексия, причем, невысокого уровня, школярского. Вижу, что вы либо не понимаете, что есть такое 1С, либо демонстрируете это.
В первую очередь 1С - это реляционная база данных нового поколения. Ни больше и ни меньше. Хотя она сейчас в стагнации и где-то даже в прострации, но этих ее качеств не отнять. Есть аналоги, но не превосходящие. Разве что нахрапом. На Западе и на Востоке.
Вы написали как вывод "Никто не ставил цель создать гибкую, масштабируемую и удобную платформу ". Ошибочка. Не знаю, что там за цель ставили кроме желания нажиться, но создали как раз гибкую и масштабируемую систему. Есть в ней и свой GIT. Своеобразный, мозолистый и свой, хотя можно использовать и традиционный, пусть и извращенно. Но извращений никто не отменял, они порой движут прогресс человечества.
Odinass-ина сейчас в стагнации и в тупике вот уже как лет пятнадцать. Ну ладно, пусть десять, потому что примерно такой срок назад начали что-то соображать и выпустили Кхултху под именем EDT. Недавно в очередной раз пощупал это убожество и с огорчением за́пил.
Главное в Odin Ass конфигуратор.
Второе достоинство - в ее функционал можно подключать внешние инструменты разными способами. Лично я предпочитаю web-сервисы, то есть базовый межпроцессорный механизм обмена через сокеты. Это и есть масштабируемость, в которую входит также свободное развертывание на сети серверов благодаря трехзвенной архитектуре. Не скупись только на сервера среднего слоя и разруливай сложный трафик. Про полный набор клиентских частей я уж не говорю, только напоминаю.
Третье достоинство - скорость проектирования благодаря конфигуратору и встроенному языку. Она может на порядок превышать типичную для sql-щины. Потому что там не просто табличные объекты, а более сложные объекты хозучета, состоящие из набора таблиц, экранных и печатных форм и поддержки платформы. Все это избавляет от цыганщины, то есть индийского кода.
А вот недостатком, который тормозит, как раз является язык. Как говорится, язык мой - враг мой. Его архаичность. Тут вы и комментирующие правы. Надо "просто" заменить его на java. Будет конфигуратор, будет поддержка учетных и коммуникационных технологий, но вместо этого убогого бэйсика честная, изящная, стройная джава. А также среду разработки (IDE) подогнать к современным стандартам в стиле IDEA или NetBeans (в силу убогости личного опыта других примеров не подберу).
Примерно так
А вот недостатком, который тормозит, как раз является язык.
соглашусь. В двух словах: сложность решений у 1с выросла на порядки. Между 2000 годом и 2025 я бы думал о 20 кратном возрастании сложности как о нижней границе оценки. И для снижения этой сложности уже нужны взрослые языки, скриптового нетипизированного процедурного бейсика не хватает.
А вот недостатком, который тормозит, как раз является язык.
Вы просто не умеет его «готовить»!
Я на нем писал много лет, и он меня практически ни в чем не ограничивал. Каким образом?
Просто потому, что у 1С есть, как минимум две возможности. Это использование внешних компонент, которые можно писать, скажем, на С++ и обмен данными с внешними системами (которые, в принципе, можно и обрабатывать на стороне).
Используя эти инструменты можно и внешний вид изменять (см. мою статью «Можно ли в 1С не соблюдать технологию внешних компонент? Или Как поздравить коллег с помощью 1С?» : https://habr.com/ru/articles/466713/ ) и доступ к внешнему движку базы данных использовать.
Так, в своей системе учета ЗП, я подключался, при расчете, к движку Visual FoxPro, через мое скомпилированное exe-приложение на VFP, которое подсоединялось к dbf-файлам «семерки», как DDE-серверу. При этом производительность работы с БД 1С77 увеличивалась в 15 раз! А саму «семерку» я использовал, в основном, как «интерфейсный контейнер» плюс там удобная система разработки отчетов.
Кстати, я нигде не встречал в Интернете, чтобы «семерка» использовала, в реальных конфигурациях, технологию. DDE.
Для работы с внешними данными, в т.ч., для получения внешней отчетности, достаточно эффективно использовал внешние обработки.
Так что вопросов с производительностью у меня не было никакой. Данные по расчету зарплаты всех сотрудников хранились с 2005 года, а это не менее тысячи человек в месяц. Сервер, при этом, был очень древний, всего с двумя гектарами памяти, но спокойно поддерживал до 20 пользователей в терминале. Смешно, но у большинства пользователей памяти было по 4 гектара, хотя весь расчет з/п велся на сервере. Алгоритмы расчета были достаточно сложными и специфическими, поэтому, официальные конфигурации нам не подходили. Тем более, что мы пережили три глобальные смены законодательств для трех государств: Украины (каждый год), ЛНР и, в конечном счете, России. Только благодаря наличию собственной системы я выходил из всех этих передряг без потерь. Путно веля учет рабочего времени по персональным картам доступа, с построением всей необходимой отчетности.
В общем, моя система работала идеально. При необходимости можно было легко увеличить ее потенциал в несколько раз, за счет небольшой модернизации на стороне сервера.
Но, всегда читаю: «Язык 1С не такой!» Да такой он! Только в своей нише. А за ее пределами переходите на другой язык, благо это возможно.
Вижу вы во всю использовали возможности Odin ass как интегратора. Это понимается не только лишь каждым. Решпект без иронии. Глянул на вашу статью. У вас ведь в основном для внешних связей используются внешние компоненты на С++ и COM-технологии? А web-сервисы не пробовали? Я увлекся этим на восьмерке после того как охладел к внешним компонентам. Писал их на Delphi для семерки и восьмерки с адаптацией структур данных к С++, есть такие приемчики. Но от версии к версии эти компоненты теряли совесть, то есть совместимость. Однажды увидел намек на использование http-подключения и спустя некоторое время выбора технологии с легкостью написал web-сервис на джаве. Можно и питоне, но джава милей, она ведь кроссплатформенная и такая миленькая. В ней собственный серверочек пишется быстро. Я таким путем спариваю Odin ass ку с Ораклом. Мне-то нужны отчеты из данных в нём, а учебная одинэсина именно как интегратор и дизайнер отчетности
Поц скриптум. С++ все-таки не для каждого, а вот джава приятнее и доступнее и вполне развернётся на линухе
У вас ведь в основном для внешних связей используются внешние компоненты на С++ и COM-технологии?
Это были демо-конфигурации. В реальной, главное было не COM, а DDE. Как я написал чуть ниже:
У меня вся серверная логика была на стороне VFP, который подсоединялся с файлам «семерки», как к своим родным. Делал расчеты и передавал результат обратно в 1С77 (см. скриншот: https://emery-emerald.narod.ru/Pics/ZP.jpg )
А web-сервисы не пробовали?
Не было в них необходимости, пока работал на фирме. А сейчас, когда не работаю, тем более.
С++ все-таки не для каждого
Ну, мы же решаем задачи не вообще, а конкретно. С Линуксом я не знаком от слова «совсем». Другие языки, для внешних компонентов, использовать не видел смысла, поскольку С++ мне очень нравится. А для решения проблем с загрузкой ВК, в последние версии 1С, делал внешний загрузчик (который внедряет любую dll в чужой процесс). Однако пока этот проект забросил, опять же, по причине, что перестал работать с 1С профессионально, т.е., на официальной работе. Поэтому балуюсь пока собственными пет-проектами на произвольные темы.
Кстати, я нигде не встречал в Интернете, чтобы «семерка» использовала, в реальных конфигурациях, технологию. DDE.
Ходить к файлам 7.7 через движки субд можно было давно. Идея "прямых запросов" и проекта 1с++ как раз была об этом. Был там парсер запроса, который разворачивал виртуальные таблицы в реальные запросы. Были даже бэкпорты табличного поля из 1с8 в 1с7 через эту компоненту и exForms.dll.
Надо помнить, что вы при этом огребаете грязное чтение. Если это норм, то применимо.
Ходить к файлам 7.7 через движки субд можно было давно. Идея "прямых запросов" и проекта 1с++ как раз была об этом. Был там парсер запроса, который разворачивал виртуальные таблицы в реальные запросы. Были даже бэкпорты табличного поля из 1с8 в 1с7 через эту компоненту и exForms.dll.
Это я в курсе. Только этот вариант меня не устраивал. У меня вся серверная логика была на стороне VFP, который подсоединялся с файлам «семерки», как к своим родным. Делал расчеты и передавал результат обратно в 1С77 (см. скриншот: https://emery-emerald.narod.ru/Pics/ZP.jpg )
Надо помнить, что вы при этом огребаете грязное чтение. Если это норм, то применимо.
Чтение и даже запись в данном случае «чистые».
Я на нем писал много лет, и он меня практически ни в чем не ограничивал. Каким образом?
Ну-ну. Как мне на 1с передать функцию в функцию, чтобы была возможность модификации ее поведения без внесения в нее правок и добавления флагов в параметры? Или как мне объявить что моя функция принимает сущности следующие конкретному контракту (например поддаются фильтрации по именам полей и итерированию), а с другими сущностями функция работать не может. Или может замыкания завезли? Ах да, уже в первом пункте упоминал, там в целом нет функций как объектов первого класса, что уж про анонимные функции и замыкания говорить.
Возможности языка вообще никак не определяются возможностями работы с разными бд или возможностями работы с интерфейсом. Это дело библиотек, компонентов и фреймворков. Возможности языка в его выразительности и удобстве построения абстракций заключаются.
Ну-ну. Как мне на 1с передать функцию в функцию
Откуда передать? Из внешней компоненты (ВК), из внешнего приложения (ВП) или из некоторого модуля 1С?
Если я вас правильно понял, то вы хотите, чтобы язык 1С обладал возможностями языка С / С++. Если вы это имеет в виду, то, естественно, никак. Понятно, что сам по себе язык 1С, хоть в «семерке», хоть в «восьмерке», очень ограничен.
Задача, лично у меня состояла в другом. Недостающий функционал я выполнял либо в ВК, либо в ВП. Внешнее приложение либо функцию из ВК я мог вызывать с параметрами из языка 1С. ВП (скомпилированный скрипт на VFP) мог при этом непосредственно работать с базой данных 1С77 и даже обновлять поля в формах «семерки» (см. скриншот: https://emery-emerald.narod.ru/Pics/ZP.jpg ). Этого для моих целей было вполне достаточно.
Для работы с произвольными dll-ками в 1С83 (где имеются ограничения на их загрузку) я делал проект «внешнего загрузчика», который вообще способен грузить динамические библиотеки в любую программу, скажем Эксел, а сам Excel, при этом, можно будет внедрить, например, в обработку 1С и работать с ним, непосредственно, оттуда. Идея интересная, но поскольку, профессионально я уже не работаю с 1С, то интерес к этому проекту как бы пропал.
Короче говоря, вы можете сформулировать вашу конечную задачу, а я, если все пойму правильно, попробую рассказать, как бы я ее пытался решить.
Ну вот к примеру, пилю я коробку на 1с, хочу чтобы тот кто эту коробку будет под себя расширять (или я сам на проекте) мог это сделать с минимальными изменениями в оригинальном коде. Как можно сделать на любом современном языке, от rust и java до js и python, создать функцию которая на вход может принимать другую функцию. Что-то вроде такого:
Функция ОперацияСДокументомРасширяемая(Документ, НекаяФункция: (Документ, Структура)->Структура)
ПредвРезультат = ВыполняемПредварительныеОперацииС(Документ);
Результат = НекаяФункция(Документ, ПредвРезультат);
Если Результат.ЧтоТо Тогда
Документ.ВыполнитьОдноДействие(Результат);
Иначе
ДругоеДействие(Документ);
КонецЕсли;
КонецФункции
// Или еще вариант, из тз получаем массив значений колонки 2 из тех строк что соответствуют условию, всяко короче и проще чем то что есть сейчас. А ведь фильтр тут может например в виде другой функции приходить, пробрасываясь как параметр на несколько уровней.
ТЗ.Фильтр { Строка -> Строка.Колонка1 > Значение }.Отобразить { Строка -> Выборка.Колонка2 }Желательно еще и иметь возможность задать требование-контракт что любой документ что передается в эту функцию должен реализовывать функцию ВыполнитьОдноДействие. Чтобы это не нужно было искать в комментарии к функции или помнить, а просто проверялось сразу, плюс если контракт вдруг усложнится - те кто функцию используют после обновления на новую версию сразу знали что нужно документ доработать, у них бы не запустилась 1с без того чтобы они исправили несоответствие контракту.
Таким образом получаем функцию, чтобы изменить поведение которой, не нужно вносить изменения в оригинальную конфигурацию, добавлять какие-нибудь флаги, новый код и т.п. А просто в разных местах использования этой функции передаем другую функцию/замыкание. Которая и меняет поведение. Очень удобно. Меньше правок в коробке для проекта, больше гибкости, меньше строк кода.
Ну вот к примеру, пилю я коробку на 1с, хочу чтобы тот кто эту коробку будет под себя расширять (или я сам на проекте) мог это сделать с минимальными изменениями в оригинальном коде. Как можно сделать на любом современном языке, от rust и java до js и python, создать функцию которая на вход может принимать другую функцию.
А почему вас расширения 1С8х не устраивают? Или, проблема именно в том, чтобы передать, в терминах С / С++, указатель на функцию как параметр?
Сама ваша задача достаточно глобальная. Я тоже думал над тем, как работать с закрытыми и даже защищенными (на уровне байт-кода 1С, который, кстати, получалось декомпилировать до уровня исходников) конфигурациями. Расширения эту проблему решают, но громоздко.
Опять же, выход видел в использовании внешнего загрузчика, который загружается принудительно в адресное пространство «восьмерки». Поскольку ВК я пишу на С++, то там проблемы с передачей в функцию, в качестве параметра, указателя на другую функцию – нет. Использовать скриптовые языки для создания ВК – не вижу смысла, да и технически это сложно. Хотя, для расчета зарплаты, я использовал скрипт, написанный на Visual FoxPro, но, чтобы воспользоваться им, я компилировал его в exe-модуль (VFP позволяет это делать).
Если вы сможете скомпилировать ваши скрипты в исполнимое приложение, то вызвать их из модуля 1С либо его внешней обработки, труда не составит. Другое дело, что могут сделать эти скрипты для ваших целей? Работать с указателями, в перечисленных вами скриптовых языках, я бы даже не пытался. Но, если сильно надо, можно использовать прослойку на С / С++.
А так да, задача у вас фундаментальная и подход к ней должен быть фундаментальным. Но, здесь надо думать, исходя из вашего общего контекста.
Как вариант, я вынашивал ранее идею внешнего функционала 1С и внешней обработки данных. Например, когда я работал с 1С:ЗУП, чтобы попытаться там сделать расчет зарплаты для нашего «сложного» сотрудника (что в своей «семерке» я делал на раз-два), то для этого мне потребовались огромные усилия. Нужные результаты я получил, но с большим трудом. Например, ЗУП, на уровне пользователя, работает с формулами, тогда как мне нужна работа с алгоритмами. Ввод и вывод данных там тоже очень геморройный.
Короче говоря, идея была такая. Выгружаем данные сотрудников во внешнюю базу данных, там делаем расчет, можно даже консольный, без ГУИ и полученные результаты загружаем обратно в 1С:ЗУП. Это позволяет нам делать специализированную отчетность там, которую самому делать влом, да и всех нюансов законодательства я могу не знать.
Вы, наверняка, работаете не с зарплатой, поэтому, мои советы вам, скорее всего, не подойдут. Но, «смысел», думаю, ясен. Если то, что вы собираетесь менять, можно вынести наружу, то можно попробовать это сделать, обработать эти данные снаружи и вернуть обратно в 1С. Может быть, этого для вас будет достаточно, чтобы иметь достаточную свободу действий, не вмешиваясь внутрь кода закрытой конфигурации. Если нет, что, скорее всего, то надо уже погружаться с головой в вашу проблему, а это время, как минимум…
А почему вас расширения 1С8х не устраивают?
Проблема расширений в том что это изменение поведения. Т.е. во первых в расширении надо делать копипаст оригинального кода и следить за его актуальностью, а во вторых он поменяет поведение и для мест оригинального вызова функции, чего не произойдет если функция принимает другую в качестве аргумента. Это если даже забыть про возможности замыканий. Нам же нужно чтобы функция вела себя по разному в зависимости от того из какого места мы ее вызываем. Плюс это очень громоздкая конструкция, а я напомню, что мы про удобство и комфорт говорим. Ваша проблема, что вы смотрите на это с т.з. низкоуровневой реализации, т.е. есть ли возможность это сделать в принципе, пусть и через костыли, тогда как речь как раз про фичи высокоуровневых языков, и построение абстракций. Т.е. это делать бессмысленно если это делать неудобно. Одну и ту же задачу можно решить функционально как на kotlin/1с, так и на ассемблере. Но наиболее удобно и просто это будет делаться именно на kotlin, как на наиболее высокоуровневом. Хоть и с потерями в перформансе в сравнении с c/rust/asm.
Плюс вы смотрите на это как на то что применяется только в избранных местах, тогда как на практике у меня на котлине код из замыканий и функций высшего порядка процентов на 20 состоит, настолько это облегчающая жизнь и повышающая комфорт и скорость разработки штука, т.е буквально, на каждые строк 5 кода есть хотя бы один вызов функции принимающий в качестве аргумента другую функцию или замыкание.
З.Ы. На 1с я уже лет 6 как не пишу, 4.5 года с 1с проработал и свалил в андроид разработку.
Нам же нужно чтобы функция вела себя по разному в зависимости от того из какого места мы ее вызываем. Плюс это очень громоздкая конструкция, а я напомню, что мы про удобство и комфорт говорим.
Пока я вас не понимаю. Мы же говорим про 1С? Какие «места» вы имеет в виду? Внутри закрытой конфигурации мы работать не должны, правильно? Тогда, где мы можем делать вызовы? Во внешних обработках 1С? Или откуда? Я же в своих рассуждениях исходил из вызова наших внешних обработок в пользовательском режиме 1С. У вас какие-то другие представления?
Представление такое, есть коробка которую нужно доработать, но так, чтобы обновлялась она без проблем сравнения/объединения. Добавляем в конфигурацию новые документы, общие модули, обработки не исправляя ни строчки из "коробки", и из них вызываем эти вот функции основной конфигурации в которые как аргументы передаем функции которые мы определили сами.
Тут же всплывают и другие проблемы 1с, с модульностью например и DI. В случае с тем же котлином это было бы взаимодействие новых добавленных модулей с библиотечными модулями. Возможно еще в DI графе вместо одной имплементации контракта подменили бы своими (используя существующую через композицию/наследование).
Этого просто не понять пока хотя бы несколько недель не попишешь фуллтайм на современных высокоуровневых языках (kotlin, swift, python, C#, js, ts, dart, etc). Ну или если есть опыт на чем то лиспоподобном. Пока это какие то отдельные примеры - оно не кажется чем то значимым, но меняет комфорт разработки качественно.
З.Ы. Еще паттерн матчинга 1с не хватает, но о нем смысл говорить появился бы только после того как завезли бы статическую типизацию. Тоже очень удобная фишка kotlin, swift, rust, пришедшая в них из языков функционального программирования.
Добавляем в конфигурацию новые документы, общие модули, обработки не исправляя ни строчки из "коробки", и из них вызываем эти вот функции основной конфигурации в которые как аргументы передаем функции которые мы определили сами.
Ну, теперь, немного понятно. Согласен с вами, чтобы вникнуть больше, нужно поработать непосредственно с кодом. Однако в этом плане неясно для меня, как вы вообще используете в одном модуле 1С разные языки программирования?
Также не понятна, какая у вас стратегия внесения изменений в поведение оригинальной конфигурации? И насколько это вообще целесообразно?
Вам не хочется иметь дело с расширениями, а мне – с зоопарком различных языков программирования, которые, то ли решают ваши проблемы, то ли создают новые. И, потом, вы же разошлись с «восьмеркой», но продолжаете быть глубоко погруженным в ней. Каков в этом смысл?
Одним словом, помочь я вам, конечно, не смогу, но уверенности в правильности вашей стратегии, относительно безопасной и удобной модификации стандартных конфигураций, у меня почему-то нет. Хотя, могу быть неправ.
Повторюсь, писал уже выше, из 1с я ушел, как раз по причине отсутствия этих вот всех возможностей, что я перечислил. Хотелось комфорта в повседневной работе и снижения когнитивной нагрузки. А этого, по моему мнению (которое для меня подтвердилось) возможно только с переходом на другой стек. Соответственно это все я применяю не в рамках 1с, а в рамках написания кода на котлине/питоне/js/dart.
Соответственно если бы это все было в 1с - возможно я бы и не ушел. И описываю я причины почему 1с стагнирует и остается дремучей древностью, когда высокоуровневые языки далеко вперед шагнули в простоте и удобстве.
Не сказал бы что я погруженным кстати остаюсь. По сути все мое погружение закончилось лет 5 назад (еще год после ухода из сферы 1с в чатах сидел). Тему эту поднимаю только вот в таких статьях на хабре, когда описываю минусы 1с (как предостережение для тех кто для себя рассматривает 1с как карьерный выбор).
Повторюсь, писал уже выше, из 1с я ушел, как раз по причине отсутствия этих вот всех возможностей, что я перечислил. Хотелось комфорта в повседневной работе и снижения когнитивной нагрузки.
Ну, сколько людей, столько и мнений.
Я, откровенно говоря, до конца так и не понял, почему отсутствие в языке 1С возможности работы с указателями явилось причиной сказать «фе» всей этой системе. Как по мне, то это ограничение, в целях безопасности, вполне уместно, для прикладных языков программирования. И делается, явно, намерено.
Я, к «восьмерке», тоже отношусь, как к вредному производству. Не приятно, но работать кому-то надо, только не мешало бы, дополнительно, «давать молоко» за ментальные травмы при работе с ней.
Хорошо, допустим, указанные вами потребности реализованы в 1С. Использовал бы их, лично я? Не уверен. Я вообще не сторонник искать решение по безопасной поддержке закрытых конфигураций в этом направлении. Ибо меня вполне устраивают те решения, о которых я упоминал: принудительная загрузка своих dll в адресное пространство 1С82-1С83, вынос части функционала 1С наружу, экспорт необходимых данных из «восьмерки» в, например, «семерку», обработка их там и возврат (импорт) этих данных обратно в 1С8х.
Главный вопрос здесь, а в чем вообще смысл в 1С? Пожалуй, только в одном – в стандартах внешней отчетности. Всё!
За годы работы с 1С77 я понял, что не важно, на чем ты готовишь данные, хоть на Экселе, не имеет значения. Важно, только, сдать внешнюю отчетность вовремя. Причем, в определенного рода полузакрытых (точнее, плохо описанных) форматах данных (типа xml) плюс всякого рода, навязываемой сверху, криптографии, электронных подписей и т.п., в которых эту отчетность принимают на госпорталах.
Вести учет предприятиями, «для себя», в типовых конфигурациях, не вижу особого смысла. Для этого лучше сделать внутреннюю конфигурацию, в которой можно получать именно те данные и отчеты, которые реально нужны, но которые, не редко, просто отсутствуют, де факто.
Теперь, насчет ухода из 1С.
Я, в силу форс-мажора, перестал работать с «семеркой» и, вообще, вынужден был уволиться. Но, если бы была возможность выбирать работу сейчас, то пошел бы на автономное среднее производственное предприятие, вроде того, в котором работал ранее, примерно, с тысячью сотрудников чтобы внедрять и работать с 1С8х там. Причем, желательно, одному. Помощников себе можно будет уже взять позже, когда текущая система заработает, как надо.
Ведь в «семерке» тоже нет никакой возможности работать, официально, с указателями. Но, это, как-то, меня не напрягало, ни разу. Ибо в этом просто не было необходимости. Но все свои проблемы я решал, как мне нужно было (вот мои старые скриншоты: от https://emery-emerald.narod.ru/Pics/Pic1.png до https://emery-emerald.narod.ru/Pics/Pic8.png ). И это можно было развивать и развивать. А 1С:ЗУП использовать только для внешней отчетности (ее, вообще, достаточно купить только в одном экземпляре).
На такую работу, я бы пошел. Только, кто меня возьмет? Сейчас, время для молодых…
Я, откровенно говоря, до конца так и не понял, почему отсутствие в языке 1С возможности работы с указателями явилось причиной сказать «фе» всей этой системе. Как по мне, то это ограничение, в целях безопасности, вполне уместно, для прикладных языков программирования. И делается, явно, намерено.
А причем тут указатели? Из всех перечисленных мной языков они только в расте есть, да и то возможностей работы с ними куда меньше чем в C/C++, на уровне компиляции обеспечивается их безопасная работа. Работа с сырыми указателями давно уже прошлый век. И даже там где она по какой-то причине осталась, вроде того же rust - настолько зарегулирована, что выстрелить себе в ногу практически нереально. Впрочем, раст отложим, в kotlin, python, js, ts, dart - указателей нет. А ссылки на функции есть, замыкания есть, и еще очень много других языковых возможностей предназначенных для прикладного программирования. В случае dart, ts, python, kotlin работа как раз более безопасная чем на 1с, за счет статической типизации (ну, в python typehinting опциональный) и более современного механизма сборки мусора (в 1с до сих пор reference counting используется, что может приводить к утечкам памяти из-за зацикленных ссылок). По факту это язык 1с более низкоуровневый в сравнении с современными языками которые куда больше для прикладной разработки подходят. 1С куда ближе к старым языкам вроде паскаля, делфи, C и т.п., чем современные языки прикладного программирования по своим возможностям и средствам выразительности.
Ибо меня вполне устраивают те решения, о которых я упоминал: принудительная загрузка своих dll в адресное пространство 1С82-1С83, вынос части функционала 1С наружу, экспорт необходимых данных из «восьмерки» в, например, «семерку», обработка их там и возврат (импорт) этих данных обратно в 1С8х.
К сожалению вы так и не поняли в чем суть тех языковых возможностей о которых я писал. Возможно я конечно плохо умею доносить информацию, не знаю. Повторюсь, суть не в том можно или нельзя что-то сделать с т.з. как оно будет выглядеть и работать для пользователя, суть в том что можно или нельзя сделать в плане средств выразительности, удобства, безопасности и скорости разработки на языке, с т.з. комфорта программиста. Как раз эта вот принудительная загрузка сторонних dll, небезопасные внешние компоненты на C++, и прочее - это то от чего мир современного программирования прикладного давным-давно ушел. Уже лет 10 как наверно.
А причем тут указатели?
Ну, хорошо, ссылки.
Работа с сырыми указателями давно уже прошлый век.
Та, хоть позапрошлый! Я вообще не понимаю мотивации: «стало хуже, зато моднее».
Если речь идет о командной работе, то да, там есть корпоративная культура, командный устав, типа, «со своим уставом в чужой монастырь не ходят», я и не хожу, поскольку люблю работать один, над проектом. Но, вы пишите только про себя, а не про свою команду, а я только про себя. Поэтому, можем позволить себе оставаться при собственном мнении или: «У меня есть собственное мнение, но я с ним не согласен!»?
К сожалению вы так и не поняли в чем суть тех языковых возможностей о которых я писал. Возможно я конечно плохо умею доносить информацию, не знаю.
Ну, вы вообще не слишком много говорите о своем контексте. Я даже не знаю, с какой типовой конфигурацией вы работаете? Что-то типа 1С:ЕРП? Соответственно, не понимаю, для каких целей вам надо передавать «функцию в функцию»? А что, по-другому никак нельзя решить вашу проблему? («А пятьсот рублей не спасут отца русской демократии? (с)») У меня такой проблемы нет, у вас есть, но почему, не понимаю. Выйти за пределы своего кода вы не хотите. Пару скриншотов дать тоже. Как говорится: «Лучше один раз потрогать, чем сто раз увидеть!» :) .
Повторюсь, суть не в том можно или нельзя что-то сделать с т.з. как оно будет выглядеть и работать для пользователя, суть в том что можно или нельзя сделать в плане средств выразительности, удобства, безопасности и скорости разработки на языке, с т.з. комфорта программиста. Как раз эта вот принудительная загрузка сторонних dll, небезопасные внешние компоненты на C++, и прочее - это то от чего мир современного программирования прикладного давным-давно ушел. Уже лет 10 как наверно.
А альтернатива какая? Вы хотите комфорта с минимумом усилий, но его нет, поэтому уходите из 1С. Я же хочу получить результат, поскольку, мое руководство не волновало, хорошо это для меня или нет? Им вынь, да положь. Если я кого и напрягал, то только самого себя. Мои пользователи на меня не обижались, Другие бы, на моем месте, перекладывали бы на них больше работы, чем я. Например, при внедрении своих программ, я очень долго мучился с переносом начальных данных из совершенно не совместимых с ними систем. Но переносил, программно, сам. Другие бы просто распечатали исходные данные на бумагу и нате вам – вводите ручками.
1С8х меня устраивает в той мере, в которой я могу самостоятельно решать, что надо, а что не надо. Результат я вам обеспечу, никого напрягать зря не собираюсь. А ориентироваться на современное, только ради моды или поддержки чьих-то мифов – не собираюсь. Кому надо – пусть выбирает «шашечки», а мне надо – «ехать».
Вот и вскрылась причина нашей дискуссии – в отношении к своей работе. У вас оно «современное», у меня не очень. Вас устраивает – ваше, меня – мое. Типичный конец всех споров – каждый остается при своем мнении.
Короче. Тушите свет! Занавес! Все расходимся! :)
Напомню с чего началась эта ветка. С вопроса в чем язык 1с ограничивает. И я все это время пытаюсь объяснить что он ограничивает в комфорте и удобстве расширения, гибкости кода. Не хотите использовать такие языковые возможности - не используйте, но тех кто их использовать хочет - язык 1с ограничивает (в отличие от всех современных языков).
Не хотите использовать такие языковые возможности - не используйте, но тех кто их использовать хочет - язык 1с ограничивает (в отличие от всех современных языков).
То, что язык 1С ограничен по определению, так это из разряда «Капитан Очевидность». Кто вообще ожидал от прикладного бизнес-ориентированного языка чего-то большего? Для этого и начинать работать с ним не требовалось. Как по мне, средств для работы там вполне достаточно, даже слегка избыточно.
Говорить нужно не столько о возможностях / ограничениях языка, сколько о задачах, которые перед нами стоят. Вы про свои конечные задачи («удобно», «комфортно», это не из этой области) ничего не пишите, поэтому и невозможно вообще вас понять, зачем нужно именно то, что бы вы хотели иметь?
Я бы хотел, скажем, чтобы фирма «1С» сделала девятую версию своей платформы проще, чем 1С8х. Ну, как M$ сделала Windows 7 проще предыдущей – Висты. Однако связывать свои решения с реализацией / не реализацией моей «хотелки», естественно, не стану. Сделают – молодцы, нет – не сильно то и хотелось.
бизнес-ориентированного языка
Так нет в языке 1с ровно ничего бизнес-ориентированного. Абсолютно. Все бизнес сущности не к языку отношение имеют, а к фреймворку и среде исполнения.
Вы про свои конечные задачи («удобно», «комфортно», это не из этой области) ничего не пишите
Не знаю почему удобство и комфорт это не из этой области. По мне как раз из этой. Задача (не бизнес задача, а те цели что я себе выбираю) - писать любой прикладной код который требуется с удобством и комфортом, а не страдать с ограниченным языком застрявшим в прошлом, который накидывает лишней когнитивной нагрузки на разработчика, вместо того чтобы через систему типов работу людям упрощать. И который не дает возможности строить свои абстракции подходящие под бизнес домен.
Без разницы что этот код будет делать, хоть флаги видимости элементам формы устанавливать, хоть график работы строить, хоть документ проводить, хоть интеграция с чем то через rest api.
Вы почему-то упорно сравниваете 1с с языками на которых писали в 90-х и нулевых. Типа старой java или C++. Но современные языки (и эволюционировавшие старые) гораздо больше подходят для написания бизнес кода, чем 1с. Единственный их минус перед языком 1с - кривая обучения чуть покруче у них, вчерашнего студента языку 1с научить гораздо проще, поскольку там из средств выражения абстракций по сути только процедуры, функции, переменные + сущности фреймворка предзаданные (и функции объектами первого класса не являются при этом). А современные языки мультипарадигменные. Совмещают одновременно и процедурное программирование, и ООП, и функциональное. Функции как объекты первого класса, паттерн матчинг и прочие фишки и подходы из функциональных языков последние лет 15 активно внедряются в мейнстрим. Сюда же можно отнести стремление работать с иммутабельными данными, возможность построения собственных DSL (в том же котлине можно довольно приятные DSL делать). Даже от null (который Неопределено в терминах 1с) сейчас принято по возможности избавляться. В том же rust например null отсутствует, хотя язык то низкоуровневый. И от эксепшенов. Вместо них Option и Result типы.
Не знаю почему удобство и комфорт это не из этой области. По мне как раз из этой.
Я имею в виду содержание, а не форму. В моем случае, содержание – это собственный учет и расчет заработной платы и рабочего времени на производственном предприятии. А форма – это 1С77 + движок VFP в виде ВП + ВК+ DDE для межпроцессного взаимодействия + внешние обработки.
У вас форма это 1С8х и… всё. Как вы лепите туда свои скриптовые языки – я так и не понял. По вашему содержанию работы у меня тоже ноль представлений. Вы не хотите об этом говорить, ну и не надо. Только и удивляться, что вас до сих пор не поняли, тоже не надо.
Вы почему-то упорно сравниваете 1с с языками на которых писали в 90-х и нулевых. Типа старой java или C++.
Да, ничего я не сравниваю. Про яву я вообще ни слова не говорил. Для меня язык 1С это просто скриптовый язык, который имеет смысл только внутри конфигуратора 1С и в его внешних обработках. Самостоятельного значения он, естественно, не имеет. С чем его вообще можно сравнивать? Вот дополнить компонентами, написанных на других языках, это уже другое дело. А для решения внутренних, стандартных задач этот язык меня вполне устраивает, поскольку, все, что он не умеет, я могу дополнить внешними инструментами.
Но современные языки (и эволюционировавшие старые) гораздо больше подходят для написания бизнес кода, чем 1с.
Я бы так не сказал бы. Язык без графического интерфейса почти ничего не стоит. В свое время, когда я изучал язык С++, когда еще никто ничего не знал про 1С, даже версии 6.0, много раз встречал в учебных примерах варианты создания бизнес-классов. И хоть один из них взлетел? Хотя идея в принципе, даже интересная. Построить, скажем, консольную «зарплату», в которой, допустим, исходные данные выгружаются, неважно откуда, в базу данных, типа SQLite, которые обрабатываются с помощью некоторой консольной утилиты и выводят результат в другие файлы, того же формата. А их уже можно экспортировать в какой-нибудь GUI-клиент. Есть же консольные графические редакторы, к примеру!
Поэтому, та же «семерка» мне интересна именно как «интерфейсный контейнер», о чем я упоминал уже здесь. В свое время, я думал, что ее можно написать самому, так как платформа 1С77 была написана за 20 человеко-лет. Я предполагал потратить в несколько раз меньше времени, за счет использования опенсорса, вроде того же SQLite. Однако задача оказалась труднее, чем я думал или у меня просто не хватило сил и желания, что, скорее всего. Там я вообще не собирался писать свой скриптовый язык, а использовать либо опенсорснывй, либо даже С++, на котором и бизнес-логику можно было писать и отладку делать. Но, этот проект дальше идей не пошел, хотя у меня ,были и исходники «2С» и аналогичных систем («Ананас», «1L»).
Другими словами, любой «бизнес-язык» без собственного интерфейсного контейнера – малоинтересен, пусть он будет хоть сто раз супер-пупер современным. А из всех доступных «интерфейсных контейнеров» – «семерочный» самый подходящий для меня, до сих пор, хоть бы он уже сто раз морально устарел. Просто, я вынужден забросить весь учет полностью, в связи с потерей работы. И заняться своими пет-проектами :) .
И, по большому счету, мне все равно, кто, на чем пишет. В данный момент, программирование для меня это развлечение, поэтому и на чем я пишу – всем должно быть «по барабану».
У вас форма это 1С8х и… всё. Как вы лепите туда свои скриптовые языки – я так и не понял.
Уже писал два раза в этой ветке, но могу и третий. Я уже шесть лет как свалил из 1с, к счастью. И с тех пор 1с снес с компа и забыл как страшный сон. И никак к 1с сторонние языки не прикручиваю и не прикручивал. Я сразу на них и пишу, без всяких 1с. Ну и предпочитаю все же компилируемые языки, вроде kotlin, swift, java, rust, dart. Скриптовые ни для чего кроме скриптов стараюсь не использовать.
1С это просто скриптовый язык, который имеет смысл только внутри конфигуратора 1С и в его внешних обработках. Самостоятельного значения он, естественно, не имеет.
Ну как же не имеет? Мы выразительные средства языка в отрыве от фреймворка с рантаймом и рассматриваем. Большая часть работы программиста это чтение и написание кода. Соответственно и рассматривать язык программирования нужно с учетом того насколько удобно с ним это делать. Какая разница какой там фреймворк и рантайм за этим языком, если сам он не обладает нужными средствами выразительности и заставляет страдать, писать по 20 строчек кода там где на других языках хватит одной, при каждой правке вносить изменение сразу в кучу мест вместо одного и т.п. Вот вообще без разницы насколько там удобно или нет формы делать, если это только 5% от времени работы программиста, 70% это работа с текстом кода, чтение и написание его + обдумывание архитектуры и абстракций, ну еще 25% на всякое вроде митингов, документации, и т.п.
Язык без графического интерфейса почти ничего не стоит.
Любой бэкенд с rest api, с которым spa работает это по сути и есть чистая бизнес логика без графического интерфейса. А какой к ней интерфейс прикручен - не важно. И большинство систем сейчас так и пишутся. Интерфейс html + js, бизнес логика на kotlin/java/C#/rust/python/js крутится на бэкенде без всякого интерфейса. Иногда к веб интерфейсу еще и мобилки добавляют, если надо.
З.Ы. То что 1с проделали огромную работу и написали очень развесистый фреймворк удобный для разработки учетных систем я не отрицаю, но язык на котором предлагается писать для этого фреймворка - ужасен.
указателей, или хотя бы вызова функций по имени действительно не хватает... Сам вендор выкручивается через Выполнить (а уж что накрутили Контур-овцы® - смотреть страшно)
А почему вас расширения 1С8х не устраивают? Или, проблема именно в том, чтобы передать, в терминах С / С++, указатель на функцию как параметр?
Предположу, что претензии не к принципиальной невозможности что-то сделать (хотя надо всегда учитывать, что 99% 1С-ников, да и вообще разработчиков, работают с кем-то до них придуманной архитектурой решения, и любые попытки привнести "свежий взгляд" могут нарваться на суровую реальность легаси и/или непонимания коллег), а к синтаксическому сахару и удобству отладки / сопровождения.
P.S. Если не путаю, то в библитеке БПО на автоматически подключаемых расширениях построена работа с торговым оборудованием, когда в основной конфигурации есть только пустые экспортные методы, а их поведение определяется текущим подключенным расширением. Задачу конечно решает, и даже в некоторой степени "элегантно", но это как предлагать сменить C на ASM с макросами. Слишком много секса в гамаке на лыжах. Хотя со временем обрастаешь готовым кодом, набиваешь руку, нарабатываешь подходы, и вот уже все это не кажется странным, и без лыж и гамака даже удовольствие кажется не тем.
ну, технически это сделать можно, но неудобно. Т.к. ни анонимных фунций, ни самих ссылок на функции не передать, то передают ее имя (вместе с неявным знанием, из какого это модуля. либо прям также имя модуля) - упаковывают все это в структуру и передают как один параметр. В целом это работает.
Язык нетипизированный, а также без подсказок типов - поэтому никаких конрактов/классов/интерфейсов не написать. Можно вставить в начало кода функции проверку входных данных и бросаться на все исключениям - на этом возможности языка пока все. Естественно, это совсем не поддержка типов на уровне IDE/компилятора/интерпретатора.
Да, экосистема 1с сильно выросла и взрослый язык мог бы снять порядочно сложностей. Если поразмышлять, почему все пришло именно к такому результату, то я бы предложил взглянуть на это все с другой стороны:
Вот к фирме 1с приходят запросы на улучшение от разных групп людей. Какие-то от разработчиков, а какие-то от бизнеса. 1с старается быть ближе всего к бизнесу (это и обеспечило ей успех в прошлом), поэтому в платформу и конфигурации попадают тонны прикладных фич на каждую 1 техническую. Отсюда отставание технической части языка.
О причинах я даже не спорю. Кроме указанной и другие есть (снизить порог вхождения и требования к квалификации какого нибудь работника франча в мелком городке, например). Тем не менее - я точно знаю что не единственный 1сник который из сферы 1с ушел по причине отставания и закрытости языка и платформы (не в плане закрытости кода, а в плане отсутствия нормальных роадмапов, комитетов, работы с коммьюнити и т.п.)
А вот недостатком, который тормозит, как раз является язык.
Тут согласен на все сто.
Главное в Odin Ass конфигуратор.
А вот тут на все 100 не согласен. Даже простой редактор вроде vs code или zed куда удобнее и более расширяемые. Да даже vim. Про Idea даже и говорить нечего, на ее фоне конфигуратор как надувная лодка на фоне старшипа.
Еще один недостаток не упомянут. Модульность и системы сборки. Подключение библиотек в 1с по сути невозможно (коммьюнити вроде что то пилит, но это как обычно, 0,001% пользователей используется).
Лично я предпочитаю web-сервисы, то есть базовый межпроцессорный механизм обмена через сокеты.
Это вот можно назвать микросервисами в какой то мере, пусть и не совсем, но никак не модульностью. Да и то, почти никто так не делает, поскольку для этого нужно кучу бойлерплейт кода писать на 1с.
Конфигуратор дает возможность очень быстро (на порядок) управлять объектами учета в БД сравнительно со скриптовыми средствами. Кнопочно и флажочно. В БД 1С объекты учета не просто таблицы. Это наборы таблиц и представлений плюс экранные и печатные формы. И все это делает конфигуратор. Практически все объекты хозучета, придуманные человечеством за пять веков, реализованы в Odin Ass. На 90%. Если что-то необходимо нетипичное сделать несложно добавить через внешнее подключение. И всем этим управляет как раз конфигуратор. Замена конфигуратора, как вы упомянули, продвинутым редактором означает все равно, что в БД должна быть реализация этих объектов учета со всем прочим сопровождением ( то есть платформа) и редактор будет вызывать эти возможности через программный код. Сдается мне, что проще некоторые вещи делать кнопочно и через специализированные средства конфигуратора вроде мастеров форм и отчетов чем описывать соединение объектов текстуально. Картинка информативнее простыни кода. Она объемнее
Замена конфигуратора, как вы упомянули, продвинутым редактором означает все равно, что в БД должна быть реализация этих объектов учета со всем прочим сопровождением ( то есть платформа) и редактор будет вызывать эти возможности через программный код.
Так она и так в БД есть. Там хранится декларативное описание формы.
Сдается мне, что проще некоторые вещи делать кнопочно и через специализированные средства конфигуратора вроде мастеров форм и отчетов чем описывать соединение объектов текстуально.
Делать - проще (не зря Дельфи в свое время так борно рванула ввысь). Но вторая сторона - управление версиями, а версии проще сравнивать в декларативном виде (не зря все эти "визуальные языки" вроде "ху*асма" и "дуракона" сдохли)
А редактор кода в конфигураторе действительно тупой. Поработав долгое время в клюшках с опенконфом - голый конфигуратор снеговика навевал уныние. Спасают только внешние средства, типа турбоконфа. EDT - и хреновая замена, и , имхо, вообще превратился для вендора в "чемодан без ручки".
Картинка информативнее простыни кода. Она объемнее
объясните картинкой "спелое кисло-сладкое, мягкое, чуть тронутое морозцем яблоко"
Конфигуратор дает возможность очень быстро (на порядок) управлять объектами учета в БД сравнительно со скриптовыми средствами. Кнопочно и флажочно
Как раз текстом это делать куда удобнее. Условно, как проще сразу увидеть что отличается от значений по умолчанию, в панели свойств среди 100 пунктов из которых изменено от умолчания два, или же когда отличия от дефолта указываются как значения полей аннотации? И с системами контроля версий так гораздо удобнее.
Код все же чаще читают, чем пишут. И соответственно для того чтобы увидеть все заданные свойства быстро - проще когда это текст, а не нужно скроллить панель свойств + мышкой тыкать в элементы конфигуратора/формы.
Не зря средства визуального программирования нигде кроме 1с и делфи не взлетели толком. Даже там где были популярны (например при создании GUI андроид приложений) последние годы уходят от wysiwyg редакторов в сторону того чтобы все делать кодом (Compose). С разработкой под ios та же история. Да и десктопные приложения сейчас больше пишутся текстом, чем накидываются в wysiwyg редакторе.
Нигде не взлетели потому что программистам нужны сверх кастомизируемые контролы. Возможность сделать что-то отличающееся от тысяч конкурентов. 1С не для этого, любое отклонение от принятого стандарта это жирный минус. Нужно десятки раз сначала подумать нужно ли делать хоть что-то нестандартное. Потому что бизнесу нужно чтобы любой новый сотрудник просто сел и работал а не выяснял а что тут в экране такое новенькое.
Нигде не взлетели потому что программистам нужны сверх кастомизируемые контролы.
Не соглашусь. Это и для абсолютно стандартных вьюшек/свойств объектов гораздо удобнее, когда все текстом.
Это не удобно, это не продуктивно. Доказательство самое простое - 1С-ник за час набросает систему с формами справочников, формами списков этих самых справочников, пару документов и пару отчетов. На что у команды пишущих текстом уйдет пара недель. Это не выдумка из головы. Чтобы получить первичный сертификат 1С Специалист за 4 часа нужно сделать фактически полноценную систему учета.
А по поводу "новинок" делать GUI текстом. Я год как хобби делал себе плеер на флуттере, пока окончательно не утонул в "удобных" портянка виджетов. В итоге плюнул на него и начал сначала на WinUI.
Я год как хобби делал себе плеер на флуттере, пока окончательно не утонул в "удобных" портянка виджетов. В итоге плюнул на него и начал сначала на WinUI.
Подходы для этого изменить нужно, да. И мышление частично.
Например, совершенно непонятно зачем вы портянки писали. Непосредственно описание дерева виджетов в визуальном компоненте не должно больше экрана-двух занимать по высоте. И то два уже многовато. И чтобы это реализовать - представление делится на компоненты и блоки, которые разносятся по разным файлам.
Условно, как это бы выглядело в случае верстки чего-то похожего на формы списка в 1с. В одном файле описывается стандартный внешний вид кнопки (и экшен в нее передается как замыкание/функция). Если действие кнопки стандартное, просто меняется тип данных, то даже функцию можно извне не принимать, а просто тип дженериком указывать. В другом файле описываем декларативно как билдится строка списка. В третьем описываем тулбар с набором кнопок. В четвертом описываем непосредственно таблицу. В пятом низ формы. В шестом все это вместе объединяем и привязываем к бизнес логике, которая сама уже в седьмом файле находится. Повторяющиеся визуальные вещи выносим в модуль стандартных для приложения компонентов, где их и стилизуем внутри (чтобы не заморачиваться со стилизацией каждого элемента когда строим непосредственно экран)
Это не удобно, это не продуктивно. Доказательство самое простое - 1С-ник за час набросает систему с формами справочников, формами списков этих самых справочников, пару документов и пару отчетов. На что у команды пишущих текстом уйдет пара недель.
Это вот вообще не так. Никто не мешает взять какой-нибудь фреймворк автогенерации форм по описанию данных, вполне себе существуют. И используются там где интерфейс достаточен стандартный (со стилизацией и мелкими правками если надо). Да прототип такого "фреймворка" с автогенерацией форм можно даже написать достаточно быстро. Если формы нужны стандартные - то кодогенерация/рефлексия в помощь, задача на несколько вечеров. Но минусы таких подходов давно известны. Потому и используются они достаточно ограниченно. Что-то не стандартное (например строки в списке с картинками нормально оформленными) реализовать либо сложно, либо почти нереально. Кастомные элементы управления для строк? Тоже печаль.
Чтобы получить первичный сертификат 1С Специалист за 4 часа нужно сделать фактически полноценную систему учета.
Есть у меня сертификат спеца по платформе, получил лет 8-9 назад. Ничего технически сложного там не было, на полноценную систему учета даже близко не тянет.
.. В шестом все это вместе объединяем и привязываем к бизнес логике, которая сама уже в седьмом файле ..
Ну вы сами то поняли какую "простоту" описали? Вместо одного места, где вы накидали компонентов, настроили привязки, настроили стиль у вас уже шесть файликов, о которых через месяц вы уже забудете. И когда что-то заходите поменять начнете метаться по окошкам в поисках заветных строчек. Я почитываю статьи которые тут выкладывают ребята из Surf, специализирующиеся на flutter. И у них это так застенчиво проскакивает "иногда сложновато в дереве найти нужный виджет".
Это же совсем не новинка. До массового перехода на xml и прочие внешние описания все GUI писали кодом. Совсем не просто так ушли на xml и подобное. Эта дичайшая смесь описания визуальной и безнес составляющей сразу отбрасывает возможность разделения ответственности. Где дизайнер может независимо от программиста набросать новые стили и скормить файлик без строчки кода. Тут он может только вам дать макетик а вы все это ручками полезете вбивать в свою кодовую базу.
Ничего технически сложного там не было
Потому и не было сложного что вся сложность уже обработана, лучшие паттерны собраны и заботливо скрыты от вас. Простая тривиальная система Склад - Номенклатура - Продажа - Отчет о продажах. Это пара недель писанины только GUI на чем угодно кроме 1С. И отдельная команда которая начнет думать как еще и backend писать. Если вы захотите это опровергнуть по сначала вспомните какие именно возможности сразу дает 1С-ный GUI. Там и фильтруемые, сортируемые как угодно списки и формы подбора и переходы из документов в карточки справочников и печатные формы и экспорт списков во внешние pdf, excell и прочее, прочее.
Ну вы сами то поняли какую "простоту" описали? Вместо одного места, где вы накидали компонентов, настроили привязки, настроили стиль у вас уже шесть файликов, о которых через месяц вы уже забудете. И когда что-то заходите поменять начнете метаться по окошкам в поисках заветных строчек.
Вот вообще не так. Тут кстати еще одна проблема 1с всплывает. Отсутствие древовидной иерархии. Вместо одного файла на пару тысяч строк, мы делаем директорию с десятком файлов по 200 строк. Где по неймингу сразу понятно какой файл за какую часть представления отвечает. Ну и бизнес логику в соседнюю директорию с именем domain кладем.
В итоге выглядит это как то так:
screen_name/
- data/
- domain/
- view/
- header
- line_builder
- list
- footer
- etcЭта дичайшая смесь описания визуальной и безнес составляющей сразу отбрасывает возможность разделения ответственности.
В 1с же из-за ограниченности этих возможностей, раскидать код по файлам в одной директории, код на форме прям регулярно еще и бизнес логику в себя включает, ибо нет возможности его положить отдельно в файлик рядом, только куда-нибудь в общий модуль, до которого из формы добираться неудобно. Ну т.е. да, вам никто не запрещает городить смесь бизнес логики и представления, как это и в 1с делалось, но это считается плохой практикой и за такое бьют по рукам, как в 1с бьют по рукам за запросы в цикле.
Это же совсем не новинка. До массового перехода на xml и прочие внешние описания все GUI писали кодом. Совсем не просто так ушли на xml и подобное.
Есть один нюанс. Раньше не было вариантов как можно писать код описания вью декларативно, только императивно. А это действительно менее удобно чем языки разметки отдельные или wysiwyg редактор. С появлением возможности декларативно кодом описывать - ситуация поменялась. Но, как я и сказал, мышление тоже надо поменять. Например, при декларативном подходе в коде мы не меняем видимость какого нибудь элемента вью по условному сигналу, как с 1с, где было: выполняем какое-то действие, меняем видимость элемента по его результатам через элемент.Видимость = Истина. В данном случае мы меняем стейт, и на основании этого стейта уже представление полностью пересобирается (а то что это делается оптимально, без пересоздания непосредственно отрисовывающихся объектов - обеспечивается механизмами рекомпозиции)
Где по неймингу сразу понятно какой файл за какую часть представления отвечает.
Это работает только в хелловрдах. Продолжим простой пимер - плеер. Обычная страничка - обложка, инфо о треке, полоса таймлайна, кнопки управления. И вот ничего из этого не принадлежит вашей странички. Все это общие виджеты которые находятся совсем в другом месте проекта, потому что на странице плейлиста они тоже нужны и на странице миниплеера и нечего плодить. И вот ваша страничка уже не линейная а простой column а вы полезли по куче-куче совсем других мест проекта искать и разворачивать десятки веток вашего "простого дерева" и на экране оно уже не помещается.
Ну т.е. да, вам никто не запрещает городить смесь бизнес логики и представления, как это и в 1с делалось
А я бы бил по рукам вот за эти domain, datа во flutter-е. После первых же пары месяцев игры в этот флуттер все разнес и все что не касается именно визуальщины сделал отдельными либами на чистом dart. В самом флуттере только ValueListenableBuilder-ы или StreamBuilder-ы. Позже это позволило очень просто закинуть мультимедию в другое хобби - лаунчер для китайской магнитолы в машине.
В данном случае мы меняем стейт, и на основании этого стейта уже представление полностью пересобирается
Да с чего вдруг это раньше не было? Ну расскажите чем эта гениальная новинка отличается от, ну как пример, Propety в JavaFX. Которые там есть аж 15 лет. По факту те же ValueListenableBuilder-ы флуттера это калька с подобных property-ей. Подписываются на изменения и реагируют на них. Ничего нового.
Это работает только в хелловрдах. Продолжим простой пимер - плеер. Обычная страничка - обложка, инфо о треке, полоса таймлайна, кнопки управления. И вот ничего из этого не принадлежит вашей странички. Все это общие виджеты которые находятся совсем в другом месте проекта, потому что на странице плейлиста они тоже нужны и на странице миниплеера и нечего плодить.
Ну так если они в других местах проекта находятся, то и в их внутренности лезть не надо. А если вдруг зачем-то надо, к примеру в зависимости от места использования меняются их настройки и аргументы, то все равно неплохо создать отдельные файлы в том месте где они используются, и их настройку под конкретное место туда вынести. Собственно я прямо на своей практике вижу что это далеко не только на hello world работает. Сам общий компонент в модуле widgets, его конкретная подстройка к месту использования и привязка логики - уже в модуле фичи в отдельных файлах, последние годы так и пишу.
А я бы бил по рукам вот за эти domain, datа во flutter-е. После первых же пары месяцев игры в этот флуттер все разнес и все что не касается именно визуальщины сделал отдельными либами на чистом dart.
Зависит от того насколько код бизнес логики независим от конкретного компонента. Low Coupling и High Cohesion. Принцип который можно применять на разных уровнях абстракции. Если какая-то бизнес логика нужна только одному экрану - то и расположить ее логично в директориях с этим экраном связанным (если вдруг будет переиспользоваться - на это есть рефакторинг). При этом получается high cohesion внутри фичи, но low coupling, поскольку в остальную программу лишнее не торчит. Внутри сама фича по такому же принципу делится. Бизнес логика отдельно, работа с данными отдельно, представление отдельно. З.Ы. Чуть поправлюсь. Непосредственно для работы с бд и сетью лучше отдельные модули выделить, и объединить это дело. Все же ту же базу лучше целиком описывать в одном месте. А вот конкретные запросы к этой базе, объединение работы с сетью и локальной базой для конкретной фичи - в этой самой фиче.
Да с чего вдруг это раньше не было? Ну расскажите чем эта гениальная новинка отличается от, ну как пример, Propety в JavaFX. Которые там есть аж 15 лет. По факту те же ValueListenableBuilder-ы флуттера это калька с подобных property-ей. Подписываются на изменения и реагируют на них. Ничего нового.
То о чем вы пишите - это скорее про двустороннее связывание, это совсем другое. Именно к описанию интерфейса отношения оно мало имеет. Это про способ установки значений полям и элементам.
То о чем вы пишите - это скорее про двустороннее связывание, это совсем другое.
В чем именно это другое? Уберите красивые слова "стейты", "декларативность "и прочие. Что у вас останется по факту - есть данные, есть описание gui. Когда где-то меняются данные вы либо в ручную говорите setState, либо за вас это делает какой-то builder. Никакой магии, никаких предсказаний о изменениях. Чистое ручное (в билдерах уже сдаланная за вас) уведомление движка - перерисуй. А что в случае "связывания"? Абсолютно то же самое, где-то есть data класс, в котором что-то изменилось и привязанные компоненты точно так же говорят движку - перерисуй меня. В чем конкретно разница, придумали новое имя "стейт" дата классу? Ну ладно, каждое новое поколение выдумывает новый сленг.
Еще раз, вы говорите о связывании данных с их отображением. Я же про само строительство представления. Как в случае байндингов делается, у стейта поле titleIsVisible, и это поле связывается со свойством isVisible вью для отображения заголовка. Теперь как в случае с декларативным созданием интерфейса кодом, у вас в принципе в случае titleIsVisible=false вью заголовка даже не создается. Просто отсутствовать будет. В случаях посложнее это особенно весело. Раньше форма делалась целиком сразу, затем в зависимости от разных значений менялись привязки, видимость, цвета и т.п. Как сейчас стейт сделан sealed классом (в случае котлина), на случай ошибки этот стейт отображается на представление в котором тупо нет вью не нужных для отображения ошибки, а второй вариант стейта, без ошибки, показывает нужные вью. Особенно весело в случае двустороннего связывания если надо серьезно представление менять, перемещать вью между группами и т.п. Оно нормально работало только если форма менялась по мелочам. В случае если нужны серьезные изменения - все становилось печально.
Честно, понятия не имею какие у вас сложности вдруг возникали при необходимости сложных манипуляций и зачем вам всю форму рисовать сразу. Никогда не испытывал сложности в любую группу добавить новый элемент кодом или вынуть лишний динамически. Точно тот же list children-ов, что и во флуттере. Точно так же xml можно использовать только для создания разметки основных разделов а содержимое наполнять кодом. А можно и все полностью кодом создавать. И точно так же не будет titleIsVisible=false так как не будет и элемента. Просто используя такой подход получите опять же малоотличимые от флуттера портянки, в общем разницы особо никакой - шило на мыло.
Да это скорее мне сложно понять что вас в флаттере не устроило. Есть 4.5 года работы с 1с (и обычные и управляемые формы), несколько лет верстки на xml вьюшек для андроида + compose (флаттер для себя только щупал + для одного подкаста приложение для работы с донатами сделал, но от compose флаттер почти не отличается). И вот на современном декларативном описании вью гораздо быстрее и удобнее работается чем с wysiwig 1с/андроида, или же там же но с программным созданием вью/версткой на xml.
Тем что декларативность это хорошо только в очень узких рамках. Вот сделали вы xml под одно разрешение, отдельно под другое и еще под несолько. Они у вас независимые, править можете раздельно. А декларировали на флуттере и бабах это все так коряво смотрится на другом устройстве. А на десктопе где окно можно изменять вообще как душе угодно все ползет, едет. И что начинается - пошла портянка тех самых if-ов какой виджет сейчас правльней впихнуть, а вот окно растянул теперь пусто стало, надо шрифт увеличить. А реальных размеров виджета то вы и не знаете, начинается везде сначала layoutBuilder чтобы узнать а какой у меня реальный размер сейчас и горы пересчета размеров шрифтов, иконок. И все это плодится и множится бесконечно.
Никто не мешает взять какой-нибудь фреймворк автогенерации форм по описанию данных, вполне себе существуют. И используются там где интерфейс достаточен стандартный (со стилизацией и мелкими правками если надо). Да прототип такого "фреймворка" с автогенерацией форм можно даже написать достаточно быстро. Если формы нужны стандартные - то кодогенерация/рефлексия в помощь, задача на несколько вечеров.
Потратьте несколько вечеров, и станьте миллиардером, как Нуралиев...
Это не так работает. Основные преимущества 1с вот ни разу не в технической сфере лежат. У них основные преимущества куча готовых коробок и сеть франчайзи, что позволяет найти 1сника почти в любой дыре, если там хотя бы тысяч 30-40 населения есть. Ну еще и в том что пользователи банально привыкли + проверено временем.
Именно. Поэтому "убийцы 1с" до сих пор кончали свой путь [роскомнадзором]. Поэтому 1с выжила и стала доминирующей. Ну и т.д.
Ну т.е. это выгодно и удобно для бизнеса. Но для разработчиков дико уныло, поскольку на разработчиков 1с плевала с высокой колокольни.
Ну так 1с и работает для бизнеса. И между "удовлетворить хотелки бизнесов" (или даже бухгалтенок) и "удовлетворить хотелки разработчиков" - вендор выбирает хотелки бизнеса. потому, что деньги ему приносят именно "хотелки бизнеса" (даже всякие "котики"). А разрабы изобретают костыли. Но несмотря на это, модель 1с более успешна. "красивый код" бизнесу не нужен, бизнесу нужно решение собственных проблем.
Еще раз, зачем мне, как разработчику вот это все когда вендор на меня плюет? Мне кажется такое даже мазохистам не очень. Лучше уйти на что-то приятное, что я и сделал.
Не самое приятное в жизни. Но "затем", зачем же мы все и работаем. Решаем чьи-то проблемы, и получаем за это деньги. Делаем это с той или иной степенью неудобства. И каждый выбирает для себя.
Готовые коробки по нынешним временам это только затравка. У них есть ИТС поддержка с обновлением отчетности, они готовы заниматься этим асенизаторством, делать из нормативной базы того качества какую мы имеем красивые кнопочки для бухш-домохозяек. Вот это титанический крайне неблагодарный труд, который вымывает всех случайных технических убивателей1С.
Так никто и не запрещает. Можно вообще форму целиком кодом описать.
Ну такое. Конкретно в случае с 1с только императивно это сделать получится. А императивный код для работы со слоем представления штука неудобная и ведущая к багам. И медленно код такой писать. Потому что Compose, что SwiftUI, что flutter - декларативное описание представления используют.
Что пнем от сову, что совой об пень. Хоть декларативно, хоть императивно - но все равно будет простынь. Сделать декларативное описание вендор мог бы (но не сделал) вообще легко, ибо внутри как раз хранится декларативное описание. Через файлы (разобранную конфигурацию) - вообще запросто, ибо оно как раз и лежит там в виде xml - рисуете свое описание, собираете конфигурацию, и вуаля.
Если вы хотя бы почитаете вводную документацию по compose/flutter, вы сразу поймете в чем различие отдельного языка верстки типа того же xml, и декларативного описания представления в коде.
В случае отдельного языка верстки вам надо всю форму(или компонент) сразу сделать, а изменения в ней каждый раз делать программно, меняя видимость элементов, перемещая их в другие группы и т.п.
В случае же декларативного описания через код, ситуация кардинально другая. У вас есть стейт, и на его основе вы формируете представление. Вместо изменения видимости элементов - у вас просто будут только нужные элементы, те которые не нужны просто не будут добавлены. Вместо того чтобы вручную перемещать элемент из одной группы в другую - он просто сразу будет в нужной группе находится.
никакой разницы. Вы либо управляете императивно, либо описываете декларативно. Из "визуального конструирования" вы получаете то же самое декларативное описание, в котором "ненужные элементы не добавлены". Единственный минус в 1с - это представление "внутреннее", добраться до него вы можете только разборкой-сборкой конфигурации ("выгрузкой-загрузкой в файлы").
Как раз текстом это делать куда удобнее.
Текст удобнее в анализе потом. Поэтому и
проще сразу увидеть что отличается от значений по умолчанию
А еще это лучше будет работать с любыми системами контроля версий. Но само написание текста дольше. Потому что (1) вносит большие задержки в wysiwyg (вот чтобы увидеть результат, нужно больше времени), (2) нужно помнить массу конструкторов с их параметрами.
Чтобы это сносно работало, крайне важно уменьшить влияние (1) - как пример, горячая перезагрузка в веб-стеке. И очень бы хорошо еще что-то сделать с (2) - например, иметь возможность выплюнуть с wysiwyg код для создания этого с нуля.
А еще это лучше будет работать с любыми системами контроля версий. Но само написание текста дольше. Потому что (1) вносит большие задержки в wysiwyg (вот чтобы увидеть результат, нужно больше времени), (2) нужно помнить массу конструкторов с их параметрами.
Ну код мы больше читаем чем пишем. А по поводу помнить конструкторы и параметры, я, честно говоря, о такой проблеме 1с вообще забыл. С тех пор как перешел на статически типизированные языки я вообще перестал запоминать какие там параметры, названия методов и т.п. есть. Автокомплит в ide, документация высвечивающаяся по наведению мышки на кусок кода плюс llm (qwen2.5-coder использую в связке с плагином continue для быстрого и умного автодополнения кода) позволяют вообще о таких вещах почти не думать. Достаточно помнить что что-то нужное в принципе существует. А в случае с атрибутами аннотаций даже это не нужно, поставил курсор между скобок, нажал ctrl+space и вот тебе весь список, что можешь захотеть добавить.
Ну почему же не должно выжить ? Грамотный маркетинг и не с таким товаром творил продажные чудеса. И потом не такое уж и чудовище...
На самом деле статья очень пропитана каким-то однобоким взглядом на объект ненависти(1С) и автор кажется не совсем правильно истолковывает связь 1С-Государство - в начале может быть так оно и было(не вдавалась в исторические факты), но сейчас мне кажется как раз таки наоборот - 1с обновляется включая в себя все изменения в законах, отчетности и т.д. Короче этот спор о принадлежности 1с к программированию может быть вечен. Иногда мне кажется, что 1С что-то вроде задрота в мире программирования, которого булят "настоящие" программисты, потому что он не такой как они.
1С никуда не развивается. А если посмотреть на внутреннее устройство. Ничего не меняется. Вышла 8.5 - новый интерфейс - ооо эта сила. Через 40 лет вижу как выйдет версия "Мы дополнили запросы оконными функциями". Если посмотреть на внутреннее устройство EDT. Это лютая дичь по эффективному использованию ресурсов. А зачем, и так сойдет. Делать мобильные приложения на 1С. Зачем? Если можно сделать на всём что угодно, но только не на 1С.
По поводу "Собственный закрытый язык" - да, автор прав. Сейчас появился кстати еще один язык от 1С, погуглите 1С: Элемент. Так уж исторически сложилось, не знаю первопричин, скорее всего калька с SAP (читай конец комментария)
По поводу "Полная зависимость от компании 1С" (по стандарты, секту и т.п.) - если автор не знает о чем то, это не значит, что этого нет. Стандарты есть, однако автор прав, что направление развития технологии диктует 1С, и оно, к сожалению, достаточно в себе
По поводу "Огромное техническое отставание" (про GIT и т.п.) - автор прав, но отчасти. В целом если бы автор зашел бы в гугл и вбил бы "1С и GIT" он бы нашел ответы на свои вопросы, но проще вбросить на вентилятор. А прав в том, что 1С достаточно в себе и "догоняет" тренды
По поводу "Служители храма" (про конфигурационных заклинателей и т.п.) - это автор видимо общается только с программистами на каком то загибающемся заводе в жопе мира, где сидят 3 программиста у которых единственная задача обновить конфигурацию. В общем кругозор у автора хромает. Я начал писать конкретно в чем автор неправ по этому пункту, но тут много получается, если хотите, отдельным комментарием дам (однако сразу скажу - те люди, которых описывает автор тоже существуют)
По поводу "Локальная цифровая резервация" - автор прав, но не по этим причинам. Были проекты за рубежом (я знаю, например, про проект сети магазинов типа "Красное и белое" в Испании), сейчас их нет по совсем другим причинам. При этом сейчас живы (это то что я знаю - если знаете, что-то еще напишите в комментариях):
https://dubai.1cbit.ru/1csoft/firstbit-erp/
Да и в 1С есть программа 1С: ERP WE которая целиком отвязана от российского бухгалтерского и налогового учета.
По другим пунктам:
По поводу не иначе как высера насчет культа сертификации и т.п. Хз, сдавал кучу сертификатов, такого не было (вот хз насколько доли юмора автора там было)
По поводу "как правильно создать документ на платформе 8.3" - ты бы вник немного в тему, почему вообще 1С думают не таблицами, а какие то документы и т. п., есть прекрасная статья на этот счет, но если не вдаваться в детали - это чтобы проще разговаривать на языке бизнеса
И в целом такое примечание - вообще некорректно 1С сравнивать с другими стеками разработки. Это технология для решения определенной категории задач, и логично её сравнивать с другими такими же технологиями. Вот, в статье был приведен SAP, у него тоже свой язык программирования ABAP который создавался как язык для разработки SAP, там тоже (насколько я знаю) все достаточно в себе. Автора же не смущает ABAP? (если что ABAP появился в 1983 - по сути, раньше, например, Питона, который в 1991 году)
По поводу "Собственный закрытый язык" - да, автор прав. Сейчас появился кстати еще один язык от 1С, погуглите 1С: Элемент. Так уж исторически сложилось, не знаю первопричин, скорее всего калька с SAP (читай конец комментария)
Первопричины заключаются в том, что так обычно делали в указанный исторический период (см. 3dsmax MAXScript, IDAPro IDC, чуть более ранний Autolisp, и т. д.). Сейчас, конечно, приколотили бы какой-нибудь liblua или libpython с биндингами через SWIG, да и дело с концом.
Вы работаете в фирме 1С?
Автор похоже даже не потрудился посмотреть какие ещё системы в начале 90-х существовали. И никто их не продавливали, народ сам хватал все что есть. 1C зашла поскольку они нормальный коробчатый продукт сделали и прикрутили возможность допилить напильником - на чем куча ИТ-шников неплохо кормилась. И зачем 1С гит нужен? Вы после сдачи баланса будете на ней тесты гонять?
«В конечном счете, будущее за гибкими и масштабируемыми платформами, которые обеспечат удобство и эффективность для всех участников рынка, а не только для бухгалтеров и госслужащих.».
И что это за масштабируемая платформа? В качестве одной могу предложить PostgreSql. :). Стандартный язык, можно генерить любые отчеты, Open Source, вот только бухгалтерию вы на нем писать запаритесь. :).
И куда вы хотите бухгалтерию масштабировать? Как был один главный бухгалтер так он один и остался :)
Вот точно никто 1с на уровне государства не пропихивал!
"для всех участников рынка, а не только для бухгалтеров и госслужащих" - вот это вообще хрень!
И куда вы хотите бухгалтерию масштабировать? Как был один главный бухгалтер так он один и остался
1с - это не только бухгалтерия
Даже если ограничиться бухгалтерией, то чуть ли не каждый второй чих чиновника может привести к необходимости протягивания дополнительной аналитики по всей системе. Иначе ФНС НДС 0% не вернет.
А если система была доработана при внедрении, что происходит повсеместно, то стандартную конфигурацию уже не накатить. А без системы контроля версий понять, что же именно надо из стандартной конфигурации извлечь - ещё тот квест. В итоге, владельцы кастомизированных решений предпочитают вести разработку самостоятельно. И тут опять нужна система контроля версий.
И именно на этом 1с и обогнала остальных - на "сравнении и объединении". Да, это не CSV/Git, но значительно лучше остальных предложений на рынке.
Вы о чем? Приведите мне хоть одну не глубоко кастомизированную конфигурацию 1С, которая была бы приемлема для экспортных операций с зерновыми.
И много ли "экспортеров зерновых" по сравнению с общим числом пользователей типовых? есть ли какие-то "общераспространенные учетные системы", в которых вотпрямклассно реализован "учет экспортных операций с зерновыми", ну а заодно еще и меркурии, чз и прочие там шубоисы?
И много ли "экспортеров зерновых" по сравнению с общим числом пользователей типовых?
Так про то и речь, что "типовое" купи-продай уходит в прошлое. И каждый второй бизнес сейчас чем-то уникален, так как иначе не выдерживает конкуренции.
Одно дело, когда когда к системе можно легко прикрутить некоторое универсальное для всех систем решение, а совсем другое - когда система требует решения исключительно в рамках своей архитектуры.
Ну вот 1с - универсальное решение. к которой вы хотите прикрутить какое-то узкоспециальное.
Я, честно говоря, не знаю, какие нюансы в "экспорте зерновых", но более чем уверен, что доработками "коробки" это решается проще, чем скрещиванием ужа с ежом.
Про нюансы я явно написал выше - НДС 0%. А прикрутить снаружи не получится, так как если учитывать НДС вне учетной системы, но на фига она тогда вообще тогда нужна?
Доработать коробочное решение можно. Так и делают. Вот только после этого обновления коробочного решения накатить оказывается дороже, чем разрабатывать необходимые обновления самому.
"типовое" купи-продай уходит в прошлое
а сторонники фузины, равно как и "бузинесс-консультант" кинзябулатов (особо он) уверены, что процессы должны быть строго типовыми. оно даже наваяло "УФМТП", в котором нет места недоплатам, частичным оплатам, недопоставкам и перепоставкам, и тому подобным отклонениям. А уж ЭДО и взаимодействие с ГосИС считаются чуть ли не злом, подлежащим искоренению. А вы хотите бесшовную интеграцию с "экспортом зерновых"
А мне лично показалось что это в 90е у каждого был свой уникальный бухучет.
А заслуга 1с как раз в том что практически всех заставила перейти на типовой учет.
Есть конечно упрямые монстры со своими тараканами, как правило какие-то заводы и производства но и их все меньше. Сложно и дорого поддерживать нестандартные конфигурации.
1с - это не только про бухгалтерию. Я заметил что многие не совсем понимают эту разницу.
1с бухгалтерия, 1с erp, 1с склад - это все продукты созданные на 1с платформе...
А 1с платформа - это просто конструктор, на котором можно делать что угодно - любое решение... Даже сайт можно сделать, хотя он и немножко убогий из-за архитектуры 1с
Он дает для этого работу с базой данных, интерфейс, и удобные инструменты для парсера всяких форматов документов ну и еще всякое, хотя больше с уклоном в работу с клиентами... По сути этакий делфи, где можно быстро накидать форм, написать события и получить софт. Только тут еще больше готовых инструментов
И поэтому эти 10500 конкурентов и убийц 1с не выжили - они все делали вторую бухгалтерию, тогда как сама 1с делала конструктор для разработки прикладного решения.
Ох, не влезал автор в тот же SAP... А уж американские финансовые системы, написанные частично на COBOL, частично на PL/1, частично на чем-то так давно забытом, что последний знавший что это умер примерно 15 лет назад (в смысле физически умер), а формочки портированы в свое время прямо с текстовых терминалов DEC VT220 на VGA, да так и оставлены.
Ой, 1C на фоне всего этого будет прям зумерский продукт.
"Я, конечно, не доктор, но посмотреть могу!"
Возможно, корень некоторых заблуждений автора статьи в его возрасте и программистском бэкграунде. Исходя из моих воспоминаний и опыта топ-менеджера достаточно крупного промышленного предприятия могу возразить:
.В 90 – 2010 е годы уважающее себя предприятие имело БЭСТ как стандарт (редко Галактику). Куда уж проприентарнее! Из-за сокращения занятости в науке, женщины в бухгалтерии частенько имели высшее техническое, а то и степень. Вопрос освоить любую БД не стоял. Но производство падало, предприятия умирали или разваливались на более мелкие, а стоимость обслуживания БЭСТ (вот она, проприентарность) была близка к первой космической. И да, тогда, на заре становления, 1С просто не удовлетворяла требованиям производственников(да и сейчас не очень!), и имела явную фискальную направленность. В то же время, 1С весьма успешно использовали мелкие торговые формочки. Защита ее сильно хромала, и ценность эникейщика зачастую зависела от его возможностей найти ломаную версию и добыть свежие обновления форм отчётности. К 2015 году в городе-миллионнике осталась одна контора с двумя спецами, способными настроить и развернуть БЭСТ. Контор по 1С были десятки (если не сотни). И помаленьку развивающийся бизнес смекнул, что проще платить за 1С, чем зависеть от эникейщика и нести риски катастрофы отчётности. Так "рыночный", маркетинговый подход победил более совершенный “технический". Так что дело не в языке.
PS И да, от русских команд в 1С до сих пор кровь из глаз. Хотя я видел команду “ПОКИНЬ" в одной из “русифицированных" версий AutoCad в 90–е!
PS И да, от русских команд в 1С до сих пор кровь из глаз.
"Как будто бы BASIC переводили "ПРОМТом" (ц).
И да, от русских команд в 1С до сих пор кровь из глаз
А вот это кстати зря. 1С-ники пишут на том языке на котором думаю, на котором они видят сны в конце концов. Если вам приходилось изучать иностранный язык по настоящему то должны были проходить определенную границу, когда мозг переключается и начинаешь думать на другом языке. Пока такая граница не пройдена человек не знает языка, постоянно думает о составе предложения, предлогах, окончаниях слов и т.д.
Подсознание любого программиста, пишущего на не на родном ему языке, постоянно переводит иностранные слова, транслирует их в свою систему мышления. Даже если это явно и не кажется проблемой. В медицине это называется ... шизофренией. У 1С-ников мозг этим не занимается, он работает в естественном для него режиме, в своем родном пространстве понятий.
Так что пишущий на том же языке на котором думает всегда будет производительней. Как вы думаете что думают англоязычные программисты глядя на код написанный на их родном языке.
Подсознание любого программиста, пишущего на не на родном ему языке, постоянно переводит иностранные слова, транслирует их в свою систему мышления.
В том то и печаль! Каждое слово (знак, термин) имеет устойчивые связи с предметом. "В начале было слово...", и по мнению многих специалистов, отсутствие слова, т.е. названия (символа), "не позволяет" сознанию "видеть" предмет. И когда к одному слову "прицеплено" множество значений, а к каждому значению множество слов, в зависимости от контекста, то мозг вынужден строить отношения "многих-ко-многим", и проводить отбор. А если слово почти знакомое, но "кривоватое" - горе! Мне проще работать с терминами (в частности иноязычными), имеющими слабое распространение в бытовой речи. Проще! Но я соглашусь, что в ряде случаев нативный язык бывает удобнее. Здесь все зависит от того, как хорошо подумал тот, кто ввел термин. И возвращаясь к "психотравме". В AutoCad EXIT -сохранить-выйти, QUIT - без сохранения. Когда же вспоминал ПОКИНЬ - попал в шкуру сказочного персонажа - сезам, откройся!
Когда же вспоминал ПОКИНЬ
Скорее всего, это было в версии 2000i, нелокализованной, когда какие-то деятели сляпали совершенно дивный перевод. Там ещё команда match properties была переведена как математические свойства.
С другой стороны, explode в русской локализации - расчленить, и оторопь вызывает:)
EXIT -сохранить-выйти, QUIT - без сохранения
Было такое творение "электронные таблицы Варитаб", типа "разработанные советско-болгарским предприятием информсистема". На самом деле это был Supercalc-3 для cp/m, "цельнотянуый", и "переведенный на русский" прямо в бинарнике. там /Q - было командой Quit, сканкоду клавиши Q на тех клавиатурах соответствовала клавиша Я. Ну и соотвественно, Quit они "перевели" как "Я кончаю"...
И да, от русских команд в 1С до сих пор кровь из глаз.
это вынужденная мера. Меньшее из 2х зол. Потому что обратное решение куда хуже: английские названия для терминов российского налогового законодательства - уж тут бы у всех мозг взорвался точно. 1с итак-то грешит названиями переменных в виде поэмы, а тут еще и неточные переводы на английский надо добавить.
Технологии должны развиваться. Если мы продолжаем полагаться на платформу, у которой внутри — скриптовая жвачка 20-летней давности, мы теряем миллиарды человеко-часов. Мы держим рынок в плену.
Я напишу здесь только одно слово - COBOL.
По поводу "Локальной цифровой резервации"... У меня знакомый в Канаде ПРОДАЕТ коробки 1С и услуги по сопровождению (его компания занимается сопровождением детских садиков: больше половины коммерческих садиков в его округе ведут учет на 1С... и не только финансовый учет, но и планирование/управление хоздеятельностью). Он живет этим заработком и не бедствует. Есть еще несколько других проектов: от стройки до магазинов разных видов... И никто там не хохочет, а очень четко считает деньги.
Я думаю, что следующая "экспертная" статья автора должна называться "Уродство low-code программирования или что такое на самом деле лень и зачем она нужна человеку".
Ну или зачем SQL если можно читать данные из текстового файла через Readln / Writeln ))
Интересно а как в Канаде справляются с 1с языком программирования?
На первый взгляд для них это должно быть примерно как для нас писать код на грузинском.
Можно писать код на английском (в т.ч. у вендора есть некоторое количество конфигураций для международного рынка, с мультиязычностью и кодом на латинице). Просто исторически, на постсоветском пространстве, код писали и пишут на русском (у этого есть бонус в виде совпадения терминов предметной области и сущностей / методов в коде).
ERP WE - на латинице.
В ОАЭ неплохо себя чувствует дочка Первого Бита (FirstBit) с бухгалтерией и своей версией ERP (которую они сделали из УНФ, кстати).
Очень односторонний "Выпад молодого программиста".
1С на рынке программ для бухучета в России по сути не имеет конкурентов по функционалу и поддержке требований в РФ.
То что стек устарел, архитектура своеобразная, ну да.
Лично меня не удивляет, что эта система работает и развивается, я в разных крупных проектах внутри банков, энергетики, розницы работал с очень чудными на первый взгляд системами и архитектурами, которые пару десятилетий уже живут и развиваются, и уверен что еще долго будут жить.
с мутной типизацией, где ошибки ловишь только на этапе исполнения
Как в том же Python, который вы предлагаете учить бухгалтерам?
Никаких стандартов, никакого опенсорса, только «мы знаем, как вам надо». Религиозная секта, а не технология
Да-да. "1С:Предприятие 8. Система стандартов и методик разработки конфигураций".
Код типовых конфигураций открыт.
Огромное техническое отставание. Где Git? Где нормальная отладка? Где тесты, докеризация, CI? У 1С-шников вместо CI — курьер с флешкой.
При работе в конфигураторе можно использовать сервер хранилища конфигурации.
EDT поддерживает git из коробки.
Тест-центр для нагрузочных тестов, 1С:Сценарное тестирование, Vanessa-Automation и т. д.
По поводу отладки: что не так с ней? Точки останова (с условиями/без), стек вызовов, получение/замена значений, что ещё требуется?
Их работа — поддерживать, а не создавать
Ну так любую систему надо поддерживать, нет?
По поводу создания — есть огромное количество самописных конфигураций, расширений к конфигурациям, так что тоже претензия весьма странная.
не хватает ни времени, ни мозгов для того, чтобы создать нечто большее
Рекомендую взглянуть на объём кодовой базы той же ERP.
Локальная цифровая резервация. За пределами СНГ про 1С никто не слышал. А если и слышал — хохочет.
Верно, но лишь отчасти.
Почему это рудимент
Собственный закрытый язык. Без модульности, с мутной типизацией, где ошибки ловишь только на этапе исполнения. Кто это вообще придумал? Как говорил один знакомый программист: «Мы тут код пишем, а система как-то выживает, пока не решит, что она совсем не работает».
Полная зависимость от компании 1С. Никаких стандартов, никакого опенсорса, только «мы знаем, как вам надо». Религиозная секта, а не технология.
Огромное техническое отставание. Где Git? Где нормальная отладка? Где тесты, докеризация, CI? У 1С-шников вместо CI — курьер с флешкой.
Служители храма. Разработчики 1С — не программисты, а конфигурационные заклинатели. Их работа — поддерживать, а не создавать. Как монахи переписывают одни и те же скрипты десятилетиями. Ибо не хватает ни времени, ни мозгов для того, чтобы создать нечто большее.
А теперь то же самое ,но для SAP. Что изменилось? Ничего. Но стоимость поддержки х100.
Аффтору надлежит не рефлексировать ,а смотреть на реальность ,сняв розовые очки.
В 90-х были системы лучше чем 1С, 1С годилась только для печати платёжек и накладных. Б.Н. сам говорит, что 1С это ERP для тех, кто не знает что такое ERP. Их фишка в том, что они заранее знали о будущих изменения законодательства и выпускали патчи раньше других. Ну и административный ресурс, подозреваю, никуда же без него.
Какая-то чушь:) Вы б хоть загуглили для начала какой инструментарий, стандарты, стандартная библиотека, девопс-инструменты и т.д существуют. Тогда б и писали. А так вброс, не более:)
Статью не читал. За заголовок пилюс))
"Для бухгалтера проще выучить 10 команд 1С, чем осваивать PostgreSQL, Python..." - Ну, как бы, да! Было бы звездец, как странно заставлять бухгалтера осваивать командлет постгрес. Эта отрыжка здесь вообще к чему?
"...и нормальный UI" - нормальный UI обычно на то и нормальный, что его не надо заставлять осваивать, он и так всем нравиться должен. Только его не бывает. Потому что для каждого UI нормален по-своему.
"Для тех, кто ещё не понял: Прошу камнями не кидать. Я не против сектантов, уважаю ваш выбор..." - что именно в твоем тексте выше должно было навести людей на мысли о твоем нежелании получать камнями по голове? Тем более после того, как ты всех инакомыслящих заклеймил своим недоразвитым оценочным суждением.
Такое ощущение, что обычного программиста Python заставили на работе разбираться и программировать 1С, мол тыжпрограммист. Обозлился, решил отыграться.
Конструктива в ушате помоев не нашел. Хотя можно было и по делу платформу обосрать. И про корявый язык и про "многозадачность". Сам не идеологический сторонник 1С, но сейчас на рынке нет конкурента 1С настолько же универсального.
Не оспаривая техническую отсталость 1С, вынужден отметить, что составить ей конкуренцию без демпинга себе в убыток можно только если законодатели, Минфин и ФНС введут мораторий на свою деятельность в области бухгалтерского учёта хотя бы лет на пять. А лучше - на десять.
За это время уже реально набрать такую клиентскую базу, чтобы затраты на последующие регулярные обновления для поддержки очередного изменения нормативных требований могли компенсироваться копеечной для клиента стоимостью поддержки.
Например, с содроганием вспоминаю введение с/ф, книг покупок и продаж. ОНА/ОНО - жуть. А НДС 0% - это вообще нечто. Полноценная реализация поддержки подобных изобретений в западной ERP системе стоила очень дорого.
Какая дерзкая нейросетка, ты посмотри.
Есть множество программ о которых автор никогда даже и не слышал, а какой яп там используется тем более. Но инженеры АСУ ТП тебе расскажут, поинтересуйся как-нибудь. Быть может тогда свое мнение об 1с изменишь.
А вообще плевать на чем написано то или иное по и насколько там используются современные в угоду технологии. Самая главная задача, что программа работает и выполняет свои функции.
Для бухгалтера проще выучить 10 команд 1С, чем осваивать PostgreSQL, Python и нормальный UI
Не знал, что бухгалтера должны учить языки программирования и иметь навыки работы с базами данных на уровне админа.
Не каждый инструмент модный и молодежный подходит под определенные задачи. Иначе на месте SAP и 1С уже давно были бы те самые современные технологии, по которым автор так рефлексирует. По факту обращаются к проверенным временем компаниям, чтобы не терять миллиарды из-за сырости системы. Ибо в любой erp такое огромное количество нюансов и мелочей, что нужны годы эксплуатации новой системы и энтузиаст из бизнеса, готовый терять личные деньги во благо мира, чтобы появилось что то более удобное для разработчика. Для бизнеса разработчик - инструмент и на сегодняшний день дешевле содержать и поддерживать то что есть, чем потратить кучу денег и десятилетия чтобы заработала новая система, которая будет удобна. Плюс долгосрочное планирование сейчас отсутствует из за мировой турбулентности, никто не хочет ждать и терпеть - ни компания ни этот человек могут просто до этого не дожить
1С пережило несколько технологических поколений, так что страдания по поводу "почему не на кубернетес" останутся где-то на уровне "между мезозоем и палеозоем был краткий миг технологии", которая быстро сменилась чередой других технологий, которые промелькнули не замеченными на фоне вечности.
В общем 1С пишутся для бизнеса, а не для резюме ИТ-специалиста, а это важно тем, кто за это все и платит.
Вот я ни разу не адепт и не фанат 1С, но автор явно накидывает:
Собственный закрытый язык. Без модульности, с мутной типизацией, где ошибки ловишь только на этапе исполнения. Кто это вообще придумал? Как говорил один знакомый программист: «Мы тут код пишем, а система как-то выживает, пока не решит, что она совсем не работает».
MS VBA вам как на этом фоне? Очень открытый? Сильно типизируемый? Придуман лично Виртом?
Полная зависимость от компании 1С. Никаких стандартов, никакого опенсорса, только «мы знаем, как вам надо». Религиозная секта, а не технология.
Тут сложно возразить, не то что MS Windows или MacOS! )
Огромное техническое отставание. Где Git? Где нормальная отладка? Где тесты, докеризация, CI? У 1С-шников вместо CI — курьер с флешкой.
Автор сам указал, что история тянется с начала 90-х. Когда никакого git'а еще в проекте не было. А тот факт, что 1С дожил до наших дней и местами работает еще версия 7.7 - говорит о многом.
Локальная цифровая резервация. За пределами СНГ про 1С никто не слышал. А если и слышал — хохочет.
Cвоими глазами видел инсталляции Торговля и Склад в Израиле, интегрированные с ККМ. Локализованые.
Видел в Финляндии однажды в магазине.
Хохочет, наверное, Б.Нургалиев от таких опусов. Я не знаю более успешного в коммерческом плане ПО за историю новой России.
Служители храма. Разработчики 1С — не программисты, а конфигурационные заклинатели. Их работа — поддерживать, а не создавать. Как монахи переписывают одни и те же скрипты десятилетиями. Ибо не хватает ни времени, ни мозгов для того, чтобы создать нечто большее.
Опять же - они есть! Специалисты. И они успешно решают бизнес-задачи. Их много и есть система сертификации, которая позволяет понять квалификацию специалиста безо вских ваших летиткод.
В общем, я думаю, что 1С еще на похоронах SAP простудится.
Обожаю такие статьи, хотелось бы их побольше везде видеть. Пускай новички не идут сюда толпами, а осваивают какие-нибудь модные пайтоны. Пока их не заменит ИИ.
Ведь они не знают, что в 1С есть куча всего интересного: проектирование интерфейсов, работа с различным оборудованием, интеграции. Общение с разными людьми. Командировки в разные места. А не хочешь - работай удаленно.
Остается только пожалеть кодеров на java или javascript или что там у вас? Какая разница? В одном случае это скучный до ужаса Spring, в другом куча говнокода.
А я пока с утречка запущу конфигуратор, потыкаю мышкой полчасика и пойду погулять, выпью кофе, подумаю над архитектурой очередной подсистемы. В конце месяца получу свои 300к.
1С говно, не идите сюда пожалуйста.
А за ABAP ещё больше платят. Я уже молчу про COBOL. Не думали переквалифицироваться?
Нет, потому что деньги в жизни не главное
Тогда к чему это было?
В конце месяца получу свои 300к.
Именно поэтому сбежал из 1с как только появилась возможность. В работе важнее комфорт, а этого без статической типизации, современных IDE, и полноценной модульности не получить.
Что ж, поздравляю. Чем сейчас занимаетесь?
Есть у вас ощущение, что современные инструменты/технологии нужны больше не вам, а вашему работодателю, чтобы вы смогли сделать больше полезной работы для него за единицу времени?
Андроид приложение для author.today пилю (ну, сейчас еще и переношу ядро на kmp, для переиспользования его в ios приложении).
С современными инструментами и технологиями ситуация win-win. Работа в современных IDE со статически типизированными языками куда проще чем работа с 1с, не сразу конечно, какое-то время на адаптацию надо. Когнитивная нагрузка снижается, там где в 1с мне нужно было помнить что если в одном месте меняю имя поля в структуре - то надо найти все места по коду и проверить что в местах где структура используется, чтобы точно знать что везде имя изменено, теперь за меня это делает IDE и компилятор. Тесты писать куда удобнее чем в 1с, банально комфортнее (хотя буду честным, их у нас мало, все таки компания мы небольшая, так что только ключевые вещи тестами покрываем). Модульность тоже упрощает жизнь сильно, приложение средне-малого размера, чуть за сотню тысяч строк кода, поделено примерно на штук 60 модулей, так что каждый из них прост для восприятия, а наружу торчит только интерфейсами, о внутренностях другие модули не в курсе, high cohesion low coupling принцип себя прекрасно показывает. Подключение библиотек так вообще кайф. Там где в 1с была БСП и всякие обработки/куски кода с мисты и инфостарта, теперь просто одна строчка в файле с указанием зависимостей. Никаких сравнений объединений или копирования кода руками, что кучу времени занимало в 1с. Да и использование этих внешних зависимостей куда проще чем в 1с было к бсп подключить какой-нибудь документ к подсистеме, куча проверок того что нужно сделать, опять же, уходит на этап сборки приложения. Почти не бывает такого что забыл что-то где-то прописать или указать, и кнопка печати не видна, как это было с 1с.
Это все конечно удобно и в плане того, чтобы делать больше работы в единицу времени, но для меня важнее, что я стал куда меньше напрягаться, и стресс сильно уменьшился от работы. Да и гонки нет такой, как с 1с проектами было. В принципе с проектами работу над продуктом сравнивать не совсем корректно, но в случае с 1с я и над проектами, и над продуктом поработать успел (в разработке 1с тоир поучаствовал). И вот как раз при работе над продуктом, а не над доработками для проектов, весь кайф современной разработки с актуальными инструментами раскрывается.
Спасибо за столь развернутый ответ, рад что вы нашли свою нишу. Видимо каждому свое. Я не особо люблю программирование как таковое. Мне сейчас на 1С комфортно: думать много не надо, изучать новое тоже. Остается много времени на хобби. Ну и конечно же многое зависит от компании и коллектива, в котором работаешь.
Я не особо люблю программирование как таковое.
Возможно в этом и разница, мне оно как раз таки очень нравится.
думать много не надо
Тут я хз, возможно если с 1с лет 15 провести что-то такое и выйдет, но по мне как раз на статически-типизированных языках думать надо меньше чем при работе с 1с, по крайней мере скучная часть думания уходит, остается только интересная часть.
А тому кто ваш труд оплачивает важнее другое. Чтобы решались его задачи, а ваше удобство для него второстепенно.
Попробуйте понять что в фокусе тут совсем не вы как разработчик а тот кто оплачивает работу. Вы тут не субъект, а просто инструмент типа лошади, которую конечно нужно кормить и чистить, но целовать в морду совсем не обязательно.
Тут главный вопрос. А мне то какое дело? Мне свой комфорт важен, и технологию на которой буду работать я соответственно буду выбирать исходя из своего комфорта, чтобы работа приносила удовольствие. Благо мы в айти, и выбор тут достаточно широкий, как из работодателей, так и из технологий, а крепостное право давно отменили.
Разрешите потоксичить? )))
А сколько вам лет?
Как давно вы получаете эти 300к? Какие перспективы?
Не приходят ли иногда в голову мысли о релокации?
Мне 30+. Получаю с конца прошлого года. Сейчас для 1С хорошие перспективы в связи с санкциями. Раньше хотелось переехать, но недоставало мотивации. Сейчас смирился, у меня и так неплохое положение.
Как в 1С обстоят дела с полным отказом от Windows? Что там с поддержкой D-Bus на клиенте? За использование Windows для обработки персональных данных очень скоро станут прилетать штрафы.
Мне действительно интересен ответ на эти вопросы, так как у меня есть целый ряд клиентов, которые уже волком воют из-за того, что то оборудование, которое без проблем через COM драйвера раньше подключалось напрямую к клиенту, под Linux подключить можно только оплатив весьма дорогую заказную разработку, да и то раком через сервер приложений.
Извините, не знаю ответы на эти вопросы. С линуксом не работаю (зачем). Про D-Bus первый раз слышу.
Вы же сами писали:
Сейчас для 1С хорошие перспективы в связи с санкциями.
А именно в связи с санкциями сертификация ФСТЭК у всех версий Windows отозвана. То есть, для любого программного обеспечения не поддерживающего Linux - перспективы, наоборот, туманны, а не хорошие.
зачем
Например, по 300 тыс. штрафа за каждое рабочее место с Windows, на котором ведется обработка персональных данных, платить вряд ли у кого есть желание.
Впрочем, если лично Вы готовы такие штрафы платить - это Ваше право
Для 1С сделают исключение. Вы думаете будет массовый переход с 1С на что-то другое? У меня лично никаких проблем нет.
Для 1С сделают исключение.
Ну может один шанс на триллион и есть, но я бы на него не рассчитывал. Судя по публикациям в СМИ и направлению законотворчества, за защиту персональных данных взялись очень серьёзно и на попятную не пойдут.
Вы думаете будет массовый переход с 1С на что-то другое?
Если 1С в ближайшее время не сделает полноценную поддержку Linux на всех уровнях - то с него точно уйдут те, кто так или иначе используют 1С для обработки персональных данных. Альтернативные решения на рынке есть. Даже SAP формально умудрились сделать российским.
У меня лично никаких проблем нет.
С линуксом не работаю
Если санкционный режим сохранится еще хотя бы 2-3 года - точно будут. Как минимум, с освоением Linux.
Но даже если санкции снимут завтра, шансы на сертификацию Windows ФСТЭК весьма туманны.
Хорошие новости.
1С поддерживает Linux и в клиентской части и в серверной довольно давно, причем в кластере могут быть машины на обоих системах одновременно. Переход MSSQL > Postgres после начала санкций - это вообще обще1Сный тренд, на котором целые компании поднимаются, вроде Postgres Proffesional или Tantor. Так что в этом вопросе вообще все ок
Ну тогда расскажите, как под Linux вместо COM-объектов, которых там нет по определению, использовать D-Bus в 1С клиенте и сервере.
Имхо. Делать обмен через COM (наверное как и D-Bus) для 1Сto1С это "сейчас моветон". Механизмы третьей конвертации - более правильное решение. А для всего остального есть например 1с шина (и другие ентерпрайз басы). Понятно, что много чего уже реализовано через COM, но раз уж мигрировать, то и может стоит обновить механизмы обмена? Более того, платформа развивается и поддержка механизмов линукса вполне может быть реализована.
Делать обмен через COM (наверное как и D-Bus) для 1Сto1С это "сейчас моветон"
D-Bus сейчас по сути единственный способ коммуникации между десктопными приложениями разных производителей на клиенте. Все остальные способы или будут загружать сервер, или будут существенно менее производительны.
Более того, платформа развивается и поддержка механизмов линукса вполне может быть реализована.
И замечательно, если будет. Но тогда почти любую разработку в 1C станет возможным вести почти на любом языке программирования, хоть на Python. И бизнес-модель 1C тогда может потребовать заметных изменений.
D-Bus сейчас по сути единственный способ коммуникации между десктопными приложениями разных производителей на клиенте
Взаимодействие клиентской части с другими программами это очень не в традициях 1С, во всяком случае современных версий: тонкий клиент и веб-клиент тем более, это вещи очень подневольные, на стороне которых кроме отрисовки и изменения UI никакой логики обычно не происходит. Файлы локальные можно еще передать на сервер, если надо, но не более. Сам же 1С еще и гнет платформу под веб-клиент, из-за чего декстопный клиент также местами ущемляется, т.к. они должны работать одинаково - можно там, конечно, побольше, но не то чтобы
Бородатый COM же был завезен для торгового оборудования, от которого в то время было некуда дется, но кроме него в платформе есть еще NativeAPI - FFI для сишных dll/so, который нормально работает в любой системе и которым проблемы обычно решаются - сейчас хайпово такое писать на Rust. Собственно, после "внезапного" роста популярности 1С на Linux, COM стал ущербным в пользу NativeAPI
Что касается связи разных систем на сервере, наиболее традиционным является RabbitMQ (вероятно, как раз благодаря появлению ~19 году опенсорсной NativeAPI либы от серьезной конторы). Ну и HTTP, который нативно в платформе есть
http подвезли в тонкого клиента недавно чуть большей свежести.
Взаимодействие клиентской части с другими программами это очень не в традициях 1С,
Так это и есть наиболее острая проблема 1С. Всё больше библиотек, драйверов, компонентов, сервисов и т.п. (в том числе и open source) есть на рынке, которые к тому же SAP легко цепляются из Java, к тому же AX из C#, и никак не цепляются к 1С без дорогостоящей разработки на C/C++/Rust и т.п.
тонкий клиент и веб-клиент тем более
Chrome поддерживает D-Bus с 2013 года. FireFox - с 2014 года. Больше 10 лет мало?
наиболее традиционным является RabbitMQ (вероятно, как раз благодаря появлению ~19 году опенсорсной NativeAPI либы от серьезной конторы)
И кто обновляет там AMQP коннектор с выходом новых версий RabbitMQ? Или пользуемся исключительно медленным легаси через HTTP/XMPP? И куда ни плюнь, одна и та же проблема. Для Java, C# и прочих языков программирования драйвера, коннекторы, библиотеки и т.п. есть из коробки, а для 1С++ их нет и быть не может.
За последние десятилетия возросшие вычислительные мощности и развитие open source сделали концепцию ERP доступной чуть ли не ИП. Поэтому, если 1С в ближайшие годы не сделает переход на Java/Python/C# и т.п., как это уже давно сделали SAP, уходя с ABAP, или MS, отказавшись от X++, то на рынке 1С будет отброшен исключительно в рамки бухгалтерии и нормативной отчетности.
Нет особого смысла спорить о технологиях, когда речь идет о смерти или жизни такой вещий как 1С. Это идалистический взгляд со стороны разработчика — поле на котором 1С не играет. Учетные системы вростают корнями в фирмы, где используются. Ни один бизнес на свете не откажется от системы, в которую 20 лет вливали деньги потому что она не «сделала переход на Java/Python/C#» и ни одна крутая современная технология не покроет в глазах бизнеса оперативный выход обновлений по изменению законодательства.
Коробка стоит копейки, франчайз есть в каждом городе, знание 1С пишется в вакансиях бухгалтеров и экономистов, а первый комментарий про смерть 1С был загружен еще по dial‑up. Многие фирмы до сих пор сидят на 7.7, которая вышла в 99 — 1С окончательно закончиал ее поддержку в 2011, а COBOL до сих пор в индексе TIOBE. Обсуждать 1С по вопросам дряхлости это база, но думать, что она умрет/скукожится/уменьшится, потому что не поддерживает D‑Bus и язык у нее старый и <some modern technologies> в ней нету — думаю нет
взгляд со стороны разработчика
Это взгляд со стороны профессионала, занимающегося внедрением различных ERP уже три десятка лет. И этот взгляд основан не на субъективном восприятии, а на том, что ведущие производители ERP отказываются от своих языков программирования и движутся в сторону открытой гетерогенной инфраструктуры. И это уже факт.
Ни один бизнес на свете не откажется от системы, в которую 20 лет вливали деньги
Вы заблуждаетесь. За три десятка лет я не помню ни одного внедрения, которое происходило с нуля, а не в качестве перехода на новую систему в замен старой.
Любой бизнес развивается и рано или поздно приходит к необходимости внедрения новой системы. По моему опыту, срок жизни ERP между внедрениями - всего 7-10 лет. Тем более, это касается 1С, где глубина кастомизаций на подавляющем большинстве проектов такова, что даже просто переход на обновленную вендором конфигурацию равноценен полноценному внедрению. С модульностью в 1С всё совсем не сладко, если не городить франкенштейна через интеграции между множеством инстанцов 1С с разными конфигурациями. Ни разу не встречал, чтобы последнее кого-то устраивало. Так делают от безысходности.
не покроет в глазах бизнеса оперативный выход обновлений по изменению законодательства
Но бухгалтерия - это крошечная часть ERP. Ну да, еще в 90-х внедрял Scala и Epicor, когда локальный бухучет был в 1С, тогда как все остальные контуры, включая финансы и контроллинг - в западной ERP. Даже в начале 2000-х, бывало, внедрял SAP с бухгалтерией на 1С. И тогда же были проекты, когда из-за производства отказывались от 1С в пользу Infor, IFS или AX.
знание 1С пишется в вакансиях бухгалтеров и экономистов
Так про это и речь. Сколько у меня ни было проектов, из всех пользователей системы бухгалтеры и экономисты составляли 3-5%. А вот 70-80% пользователей - это производство, логистика, закупки и сбыт, для которых эти бухгалтеры и экономисты - затратная статья фискального учёта.
до сих пор сидят
Какая разница на чем сидят? Рассчитывать только на поддержку уже имеющихся клиентов - тупиковый путь и регресс. Доходы получают с новых внедрений. А так как стоимость владения 1С, относительно других систем на рынке, становится всё дороже и дороже, то выбор бизнеса предсказуем.
Общий рост рынка ERP в 2024 году составил от 10% до 15%. В основном за счет продолжения крупных проектов в промышленности и миграции на российские ERP в госсекторе. Вне госсектора почти все в ожидании движения к модульным решениям, позволяющим компаниям интегрировать специализированные сервисы для различных бизнес-задач вместо создания громоздких монолитных систем. Переход к гибким, быстро реализуемым проектам, которые закрывают текущие потребности бизнеса на горизонте 3–5 лет, защищает компании от долгосрочной зависимости от одного решения, снижает сроки реализации проектов.
И если 1С не будет двигаться по этому пути, то найдутся те, кто этот рынок займут.
1С-Рарус показал рост только за счет госпредприятий. Терралинк с SAP (включая "российский" SAP) занял второе место. IIKO с собственным решением уже на третьем месте. Бывший лидер, Борлас, свалился на шестое место, так как специализируется только на 1С. Ланит вообще исчез с горизонта.
Тенденции рынка не видите? Почитайте, интересно.
С модульностью в 1С всё совсем не сладко, если не городить франкенштейна через интеграции между множеством инстанцов 1С с разными конфигурациями. Ни разу не встречал, чтобы последнее кого-то устраивало. Так делают от безысходности.
И в соседней ветке предлагают внедрять ERP, которая модная-стильная-молодежная-открытая-модульная-и всё такое, только она "выгружает данные для 1с". И подключается к ККМ только через Распберри... Но да, "не на языке 1с", круто же..
Хотя с модульностью у 1с чуть более, чем дерьмово, и это принципиально неисправимо (точнее, принципиально-то возможно, но на практике им для этого придется переписать чуть не всё своё ERP, откуда они "выкусывают" УТ и ЗУП полностью).
из всех пользователей системы бухгалтеры и экономисты составляли 3-5%. А вот 70-80% пользователей - это производство, логистика, закупки и сбыт, для которых эти бухгалтеры и экономисты - затратная статья фискального учёта.
Ну так везде. Из 60 пользователей - 1 главбух, 1 финдир, 1 аналитик, подчиненный финдиру и коммдиру. И ничего, от остальных тоже требуется знание 1с в той общей части, которая позволяет отличить справочник от документа, и настройки отчетов (хотя бы наложения фильтров).
Доходы получают с новых внедрений. А так как стоимость владения 1С, относительно других систем на рынке, становится всё дороже и дороже, то выбор бизнеса предсказуем.
Объем новых внедрений может расти только при росте экономики. остальное - переходы.
она "выгружает данные для 1с"
И правильно делает. Пусть фискальная российская бухгалтерия живет в 1С. Это не оперативный учёт и никакой необходимости иметь её в среде ERP нет.
И подключается к ККМ только через Распберри
И то хорошо, что хотя бы так поддерживаются древние ККМ. Современные ККМ подключаются через USB/Ethernet/WiFi/BlueTooth и явно не требуют дополнительного железа.
от остальных тоже требуется знание 1с в той общей части, которая позволяет отличить справочник от документа, и настройки отчетов (хотя бы наложения фильтров)
С точностью наоборот, под остальных надо делать эргономичный ввод и витрину в BI. И куда дешевле во владении, когда это отдельные модули, а не что-то интегрированное в общую конфигурацию. Ну не будет водитель автопогрузчика на складе пользоваться интерфейсом 1С. Так же как и оператор ЧПУ, и инженер из CAD, и менеджер по продажам из CRM, и логист из системы слежения за транспортом.
Объем новых внедрений может расти только при росте экономики.
Во-первых, необходимость новых внедрений определяется не макроэкономическими показателями, а потребностью конкретного бизнеса. И в связи с санкционным давлением и повышенным спросом со стороны ВПК эта потребность только возросла. Во-вторых, уже третий год наблюдается устойчивый рост экономики в РФ.
Очень интересно! А что такое обработка персональных данных? В смысле вот есть обычное рабочее место, мне надо переслать письмо содержащее мои ПД например в журнал - ну там... лицензионный договор, и т.п... Теперь так нельзя?
А что такое обработка персональных данных?
обработка персональных данных - любое действие (операция) или совокупность действий (операций), совершаемых с использованием средств автоматизации или без использования таких средств с персональными данными, включая сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, передачу (распространение, предоставление, доступ), обезличивание, блокирование, удаление, уничтожение персональных данных;
мои ПД
Со своими персональными данными можете делать что хотите.
Действие ФЗ от 27.07.2006 N 152-ФЗ "О персональных данных" не распространяется на отношения, возникающие при обработке персональных данных физическими лицами исключительно для личных и семейных нужд, если при этом не нарушаются права субъектов персональных данных. (Ст.1, п 2.1)
После прочтения вспомнился один старый бородатый анекдот. Постараюсь его перефразировать.
У сервера 1С расположилась толпа бородатых, волосатых, в наколках 1С-еров... Пьют пиво, настраивают бизнес-процессы. Мимо проносятся молодые зумеры-итшники, с докерами и кубренетесами, деплоят микросервисы с огромной скоростью... Сначала на тест, потом на прод. В одну сторону, потом обратно, опять и опять... Через некоторое время останавливается один из них и обращается к продолжающим пить пиво 1С-никам:
— Слышь, братва, давай хоть познакомимся — вы ИТ-шники, мы ИТ-шники, а не общаемся...
— А что с вами знакомиться — вы ж каждый год НОВЫЕ!!!!
Спросил у ChatGPT каккие есть альтернативы 1C он выдал Open Source решения:
GnuCash https://www.gnucash.org/ - Десктоп-приложение, ориентированное на малый бизнес и частных пользователей. Реализует двухстороннюю систему учёта, позволяет вести учёт доходов-расходов, банковских операций, инвестиций и строить разнообразные отчёты. Поддерживает Windows, macOS, Linux.
Odoo Community https://www.odoo.com/ru_RU - Полнофункциональная ERP-система с модульным принципом: учёт продаж, закупок, склада, бухгалтерия, CRM и многое другое. Имеет официальную русскоязычную локализацию и возможность доработки под требования российского законодательства через сторонние модули.
ERPNext https://frappe.io/erpnext - Открытая ERP-платформа на базе Frappe Framework. Включает функционал бухгалтерии (многовалютность, автоматизированные проводки, отчёты), CRM, складского и проектного учёта. Поддерживает русский интерфейс и локализацию.
Akaunting https://akaunting.com/ - Онлайн-сервис с открытым исходным кодом, подходящий для фрилансеров и малого бизнеса. Предоставляет инструменты выставления счетов, учёта затрат, автоматических напоминаний по платежам и базовую бухгалтерию. Имеются расширения для локализации.
Кто пользовался или слышал за эти программы или другие программы, поделитесь мнением как они?
Могу сказать, что даже если все особенности бухгалтерского учета РФ отражать проводками вручную, реализовав корреспонденцию счетов на субсчетах, то замучаешься получать из этих программ как формы текущего учета, так и отчетные формы для ФНС.
По проводкам регламентированная отчетность отлично собирается.
Знаю организацию где первичка вся ведется в самописной конфе (так исторически сложилось, своя производственная конфа, а-ля ERP), и все потом грузится в 1С БП проводками (ручными операциями) с заполнением некоторых регистров. И потом из БП отлично формируются все требуемые регламентированные формы. А отчетность оперативного учета в своей конфе. Зато удобно, когда нужно нестандартное отражение операции нет необходимости воять в БП новый документ. Главбух просто перенастраивает правила конвертации... правда конечно там главбух немного понимает 1С как бывший программист, в том числе и на 1С.
Покажите, например, как по проводкам собрать декларацию НДС 0%. Особенно, если закупалось сырье, а экспортировался результат его переработки.
Могу проще пример привести. Расскажите, как посчитайте амортизацию только по проводкам без карточек ОС.
Я же упомянул "... с заполнением некоторых регистров". Вполне возможно, что отдельные справочники и документы все таки заполняются и в БП, уточню детали реализации.
По проводкам регламентированная отчетность отлично собирается.
Я жду примера формирования декларации по НДС 0% из GnuCash.
Вы же оспариваете моё "замучаешься получать", утверждая, что "отлично собирается". Вот и покажите.
Ну хорошо, был не точен, переформулирую - большая часть видов/типов отчетности ХОРОШО собирается. Естественно есть моменты про всякие подтверждения: книги покупок/продаж, реестры и регистрации счетов-фактур, таможенные декларации и т.п., там где нужна информация из реквизитов документов.
Я уточню как они обходятся в этом случае. Скорее всего формирует необходимые документы при обмене.
большая часть видов/типов отчетности ХОРОШО собирается
С чего Вы это взяли? Докажите.
Особенно интересно, как Вы будете амортизацию ОС считать на проводках без карточек ОС. А без этого даже баланс и отчет о прибылях и убытках не сформировать.
Особенно интересно, как Вы будете амортизацию ОС считать на проводках
Он же сказал не "на проводках", а по проводкам. Т.е. если амортизация отражена проводками, то баланс собирается.
Ну а чтоб сформировать проводки по амортизации - естественно, нужна аналитика (карточки ос, спи, нормативка).
Он же сказал не "на проводках", а по проводкам. Т.е. если амортизация отражена проводками, то баланс собирается.
Баланс собирается, но декларацию по налогу на имущество как он собрался формировать по проводкам? Особенно, разделы 2.1 и 3.
Баланс собирается, но декларацию по налогу на имущество как он собрался формировать по проводкам
Ну, во-первых, он сказал "большая часть отчетности ", а во-вторых, нынешняя наша структура налогообложения (которая хорошо выражается словом "налогооблАжение") требует особой аналитики. Если вспомнить старые идеи, где налог на имущество - простой процент от стоимости, то всё значительно упрощается. Ну никто ж не утверждает, что "на проводках" нужно строить учет акцизных марок, всех этих наших егаисов и честныхзнаков, вкупе с зерном и меркуриями (не, можно, конечно, но будет это отдельный изысканный геморрой)
Ну, допустим. И что дальше то?
ИМХО это с любой специализированной системой так.
Пользователь знает чего он хочет, знает, вообще говоря, как ему решать задачу - у него задача КАК ЭТО СДЕЛАТЬ ИМЕННО СРЕДСТВАМИ ДАННОГО СОФТА.
А том же Ansys (который вообще о другом) - обучение - то же посвящение и откровения. И в случае чего есть техподдержка.
1С это зеркало налоговой службы. Никто бы не добавлял в систему проимочки, если бы они были совсем не нужны. Но нам нужно.
В США я пользуюсь Quickbooks, но с той же радостью я мог бы всё собрать в эксельчике, для малого бизнеса. Если я плачу инвойс, то вот он скан инвойса, а вот она транзакия по карточке. Мне ничего более не надо. Мне не нужен товарный и кассовый чек, накладная, счёт фактура, разрешение от правительства о возможности моей оплаты инвойсов и тому подобные вещи.
Когда я подаю налоги, мой налоговик за 4 минуты считает что-то там примерно на калькуляторе, после чего налоги уходят туда куда надо и всё довольные. Потом мы через квикбукс сделаем сход-развал, и доплатим 1000 баксов туда или сюда.
Когда я подавал налоги в России. Ну, рядовому гражданину это было легко. Вы об этом не задумываетесь. Но, подавать налоги НЕ рядовому гражданину - это полные треш и пиисец.
Я помню, как вернулся в Москву примерно 2 года спустя, после того, как переехал в США. Бухгалтер старой компании, в которой я работал, узнала об этом по ВКонтактику, через моих друзей нашла мой номер и приехала за пол-города, чтобы выдать мне 760 рублей, которые я недополучил при уходе из компании. Мне пришлось подписать две бумаги, а она выдохнула так, что я бы не удивился, что у неё в этот момент оргазм был.
Когда тебе надо заниматься навигацией в таком поле, где за каждым поворотом ржавая мина, а каждый закон обременяется уголовочкой, где каждый рубль - это то, за что надо сражаться, то понятное дело, тебе нужен 1С, который был написан людьми, которые знают, что это такое.
В США я всегда могу списать то, что я недосвёл в отчётности на личные расходы, доплатить 50 баксов налогов на это, и забить.
(Всё вышенаписаное подразумевает, что вы НЕ занимаетесь мутными делами и НЕ пытаетесь никого наиипать)
вы НЕ занимаетесь мутными делами
А, то есть не Россия! Тогда другое дело.
Вы свалили все в одну кучу. Бухучет и отчетность перед ФНС маленькой компанией и большой компанией. Налоговый учет компании средней руки и физического лица. В РФ это все сильно разное. Где-то наверное прилично более стремно чем в штатах, а где-то сильно лучше.
К примеру, в РФ вы как физ.лицо в 99% случаев вообще не будете заниматься такой развлекухой как сдача отчетов в налоговую и оплата налога на доходы. Это все за вас сделает ваш работодатель и это его головная боль. В штатах ведь каждый гражданин "развлекается" с расчетом налогов и их уплатой самостоятельно каждый год. И по косвенным данным этот тот еще квест ))
Если вы ИП в России, то бухучет за вас может автоматически делать банк, где у вас открыт расчетный счет. Также банк за вас подготовит отчеты для налоговой и платежки для оплаты налогов. Вам останется только подписать это условной КЭП. Это если вы работаете без сотрудников. С появлением сотрудников все становится веселее.
Еще проще если в РФ у вас статус самозанятого. Вы просто платите 4% или 6% от дохода раз в месяц, занося каждый входящий платеж в систему учета. Сумма налога считается автоматически. И собственно все.
А вот если у вас в РФ у вас ООО с сотрудниками, то все становится сильно веселее. Причем с каждым годом все веселее и веселее ))
Мне думается вы тут смешали две проблемы.
1. Практика разработки софта в конкретной конторое - 1с и что из этого вышло.
2. Архитектурное решение для бухгалтерской и ЕРП задач, реализованное 1с и последующее создание из него экониши.
У меня есть серьезные претензии по 1му пункту. Криворукость там подтверждается массовыми утечками от самих разрабов и их начальников.
Есть претензии и по 2му пункту, в части правильности избранной стратегии, но они скорее от послезнания чем результат который можно было получить тогда. В те годя я бы пошел тем же путем. Сейчас, с опытом, понимаю принципы заложенные и в САП в том числе.
Но это больше критиканство будет. Так что с точки зрения бизнеса в 1с-корпорации все сделано верно. Той же дорогой идет Сбер и не только он. Но будучи банком попадает под массу регуляторных ограничений и потому там это не развивается в жесткую херню но потуги были и есть.
Самим ругать 1С уже лень, теперь просим нейронку это сделать?
А для меня 1С - это хороший тестовый полигон. SQLSmith, SQLancer, JOB - всё это детские игрушки. 1С-ная инсталляция под нагрузкой - вот он аналог конструкторских испытаний перед сдачей кода в эксплуатацию!
Ну и да, есть ещё вторая функция - в 1С-ных запросах можно найти любопытные SQL-паттерны и оценить, справляется ли оптимизатор моей СУБД с ними и где у него есть ещё слабые места. Этакая подготовка ко временам, когда AI-агенты будут сами ходить в базы и выполнять аналитику - какие SQL они там будут генерировать, одному Марксу известно. Но справляясь с 1С мы имеем хоть какую-то надежду справиться с этим неконтролируемым валом запросов произвольной сложности.
Я что-то не припомню, чтобы в 90-х Нуралиевскую 1c продавливали прямо административно. Как ни странно, но был свободный рынок и 1с смогла его завоевать ))
Не знаю кто может составить конкуренцию 1с в громадных компаниях, но в области простого учета есть вполне успешная онлайновая Эльба от Контура. Есть несколько знакомых на Эльбе - все довольны.
Также отжирают свой кусок автоматизированные системы бухучета в крупных банках, где в дополнению к обслуживанию расчетного счета за 5 копеек предлагают автоматизированную бухгалтерию. По памяти это есть в Т-Банке, Модуле, скорее всего и в остальных Сберах, Альфах, ВТБ и т.д. должно быть.
Думаю, как раз экосистемы крупных банков со временем смогут составить приличную конкуренцию 1с. В этих системах все будет в одной коробке: банковские продукты, система бухучета, система отчета перед гос.органами, система кадрового учета, управленческого, складские и т.д.
кстати о банках. В банках для своей основной операционно деятельности и налогового учета никогда никаких 1C небыло. И сейчас нет. И не будет. Это либо самописки, либо всякие коробки от полудюжины вендоров типа ЦФТ. И ничего. Работает как-то. Никого не смущает, что это не 1С.
Естественно, что в банках работает АБС - Автоматизированная Банковская Система. Есть самописки, есть готовые решения. Ну как готовые - ядро + понятный и документированный механизм расширения и адаптации.
Банк сложнее там счета-проводки это только малая часть. Там еще клиентские данные, контроль платежей, комплаенс... И баланс в банке сводится не раз в месяц, а каждый день (закрытие банковского дня - EOD). Плюс жесткий контроль со стороны регулятора. Плюс нормированные требования на максимальное время недоступности. Плюс кредиты-депозиты-лимиты-тарифы... Плюс регулярная отчетность... Много чего всего.
1С там просто не вывезет. Ни по объему данных, ни по количеству операций в сутки, ни по функционалу.
Так что это совсем из другой оперы.
закрытие банковского дня - EOD
когда-то это называли емким словом Пердень (от ОперДень)
Ну тут кто как. У нас в основе импортная система - там EOD. Перед которым идет BEFRUN (подготовка юнита к переходу), а после - USRAFT - завершение всех операций и начало нового дня.
Но тут специфика в том, что мы работаем в реальном времени. Т.е. банк продолжает обрабатывать платежи и во время EOD. Для этого в BEFRUN создается копия дневного юнита - юнит ночного ввода и все операции переключаются туда.
А после EOD происходит "накат из ночи" - все изменения, что произошли в юните ночного ввода за время EOD, переносятся в дневной юнит, в новый день.
Все это, конечно, добавляет геморроя, но как есть... Как раз недавно ошибку искал - одна из операций не переносилась. Там была составная транзакция, когда изменение в одной из таблиц тянет за собой изменения еще в нескольких. И все это надо корректно перенести из ночи в день. И вот одна из таблиц не переносилась... Долго искал т.к. отладчиком туда не залезешь, только трейсы в таблицу логирования. Да и не погоняешь так просто - нужно юнит перевести в ночь (время), ввести тестовые данные, убедиться что все корректно вкатилось в ночи, потом юнит обратно в день (опять время) и смотреть по логам что где не так пошло. За день максимум пару раз успеваешь это дело провернуть. А ошибка была уж очень неочевидная. К тому же там три программных комплекса были задействованы и непонятно в каком из них ошибка.
Когда то давно появился многообещающий аналог — Бухгалтерская программа «Сибирский Ананас» https://sourceforge.net/projects/ananasproject/
Опенсорсное кроссплатформенное решение с теми же принципами как у "1С-Страдания", но лучше:
- GUI на C++ и Qt
- Встроенный скрпитовый язык разработки
- Совместимость с опенсорсными базами данных
Еще тогда, много-много лет назад, я исследовал эту программу как альтернативу для перевода компании среднего масштаба. К сожалению, проявились нюансы, из-за которых почти сразу пришлось отказаться от этой идеи:
- Программу разрабатывали пара седых ребят исключительно на энтузиазме. Этого оказалось мало для доведения программы до уровня конкуренции с оригинальным решением.
- Qt фреймворк очень быстро эволюционировал и программа сильно отставала в миграции на новые мажорные версии. Это вызвало то, что на новых версиях Linux уже невозможно было найти библиотеки такой древности (и да, в компании на десктопах был Linux и бухгалтерия была единственным рудиментом, сидящим в терминале на винде ради той убогой 1C)
- Встроенным языком был какой-то аналог JS внутри самого фреймворка Qt (сорри, подробностей не помню а уточнять — лень). Если ничего не путаю, то даже сами Qt потом отказались от поддержки этого языка в следующих версиях фреймворка по причине его крайней убогости и сложности освоения.
- На тот момент развития программы невозможно было с помощью встроенного языка заменить весь фунционал 1С. Даже с учетом готовности компании переписать с нуля абсолютно всё, что было написано для 1С ранее, к сожалению, этого бы не получилось сделать в принципе!
Похоже, проект Ананас давно сколлапсировал, хотя исходники по-прежнему доступны и на удивление, официальная страничка до сих пор работает: http://ananas.su/
Искренне желаю процветания любым альтенативам типа "Ананас". Может быть кто-то решится и сделает аналогичное с нуля, или доведет до ума уже имеющееся! Ведь туда были заложены просто превосходные идеи, да и реализация была вполне годной. Хотя сейчас привязка к Qt кажется серьезной архитектурной ошибкой именно по причине отсутствия обратной совместимости новых версий со старым ПО на фоне эволюционирования на стероидах.
Еще была какая-то наколеночная альтернатива на Пютане (простите за мой французский), которая даже обещала 99% совместимость с оригинальным встроенным языком программирования гоВДноэски, но сейчас мне не удалось найти даже упоминаний, так она была популярна! :-D Может кто вспомнит?
Очередной писатель убийцы 1с, который считает что ее можно убить простым круд приложением на любимом питончике.
Как вступить в секту 1с? (C) Паша 40 лет, devops. Глаза разбегаются уже от этих ваших модных кубер докер технологий :-)
Хабр продолжает превращается в помойку
Прям представляю, Минфин с ФНС и Ростат, а не замутим новую темку, что б 1С поболее заработало и аффтор со своими технологиями провалился.
1С была, есть и будет
Попробуйте отучить кота гадить в ванну
Жена отучила кошку ссать периодически в ванную простым наполнением ванной водой сантиметров так на 10. Кошка запрыгивает, понимает, что как-то мокровато, и уходит.
(Проблемы с этим инновационным подходом вскрылись позже, когда кошка в какой-то момент пожала плечами, сказала "Ах, так?" и начала ссать в ванной на пол, и смыть это душем за 10 секунд уже не получается. Но это следующая итерация непроходящей войны жены с моей кошкой)
А уже были в комментах эти самые сектанты? Помнится на хабре видел как некоторые из них писали в комментах, что все эти "лучшие практики" есть в 1с, там и докеры, и кафки, и редисы, и гитхаб, и вообще всё. И что это всё враньё про отсталость...
И что это всё враньё про отсталость
Так есть то оно есть, да только в той среде всю эту красоту мало кто использует – поздно появилась, да и само сообщество… гм, скажем, с немейнстримовыми ухватками.
Ради прикола вбейте в гугл что-нибудь типа «код на 1С», переключитесь на картинки – и посчитайте, на скольки скриншотах вы увидите для начала номера строк (тут шансы есть), а потом не вырвиглазную чёрно-красно-синюю тему (а вот тут почти без шансов).
А что за культ с номерами строк?
Ну вы прямо фильмы про хакеров не смотрели... там обязательно номера строк должны на мониторе быть...
А что не так с номерами строк? С ними удобнее
В мире 1С слово «удобнее» запрещено. Там для всего свои закодированные названия, и вместо «так удобнее» там «это методически неправильно». /sarcasm
А зачем они нужны на экране?
А зачем они нужны на экране?
Чтобы быстрее объяснять. "Вот смотри, на 10-ой строке мы... а потом на 14-ой"
Ни разу в жизни за 40 программирования лет такого не требовалось. Ни в одном языке.
Ни разу в жизни за 40 программирования лет такого не требовалось. Ни в одном языке.
Вы ни разу в jetbrains issue не отправляли?
Нет.
Или на github/gitlab? И никому из коллег не писали про что-нибудь в коде? Типа, вот вы в такой-то строке написали так, а надо так?
Обычно хватает указания процедуры. дифф дает номера строк, если надо перейти - можно по ним.
Но и строку могу при необходимости указать - номер строки отображается. Перейти на строку с нужным номером коллега (или я сам, по номеру строки в сообщении об ошибке, например) может очень легко, нажатием ctrl-g. Номер строки на экране тут совершенно не нужен.
У нас на фирме (а это в той половине, где ничего не слышали про 1С) практически с момента основания, а это 21 год назад, в качестве ERP использовалась ABAS ERP. Ну так где-то более 15 лет. Все работало, но было очень много костылей под свои нужды.
Наконец некоторому умному человеку пришло в голову, что система отстой, костыли вот-вот упадут, нужно что-то новое, прогрессивное, трендовое, и в результате было принято стратегическое решение перевести весь бизнес на BC. Сказать, что переход дался трудно, ничего не сказать. Процесс внедрения занял 2(два!) года, первый месяц после запуска ни один из разработчиков практически не спал, и сейчас, спустя чуть больше года, всё еще куча нерешенных проблем и багов, практически каждый день тикеты с проблемами импорта-экспорта, и тд и тп. А бухгалтерия и продажа, все те, кто каждый день работает в системе, до сих пор не могут привыкнуть к новому зверю, а поначалу вообще впали в полное коматозное состояние от шока.
Автор не в теме. Зачем-то говоря про истоки приплетает иностранцев, которые якобы не спешили. Да они все тут были. И сап, и суперкальк и огромные буумажные простыни. И на отечественном рынке бэст, галактика, парус, бэмби, турбобухгалтер, альтер и т.п. это только то что вспомнил.
И да, 1с стала отраслевым стандартом в кровавой борьбе, предложив схему дистрибуции которая угробила конкурентов.
Про предметно-ориентированные языки, стоимость разработки и владения автор не знает, про унификацию и бас фактор тоже.
Статья написана хорошо, но читается как фантазия оторванная от практики как книги Берроуза про марсиан
предметно-ориентированные языки
Вот только SAP активно переходит с ABAP на JAVA, AX - с X++ на C#. Они тоже не понимают пользу предметно-ориентированных языков? Или всё же ERP явно переросли предметную ориентированность, покрывая уже намного более широкую сферу хозяйственной деятельности, чем это было раньше?
Какая на фиг "предметная ориентированность" если последняя буква в ERP подразумевает использование сложнейших математических моделей для прогнозирования и поиска оптимумов?
Как раз реализация концепции ERP - это огромная головная боль в рамках 1С архитектуры. В итоге клиенты начинают сами прикручивать сбоку дополнительные БД, которые уже являются источниками данных для питонов или юлий, в свою очередь работающих с математематическими моделями и различными солверами.
Вот только это уже не ERP получается, так как балансировка и оптимизация становится дискретной, а не непрерывной.
Скажите, если мы начнем обсуждать автотранспорт, вы по этим словом будете понимать исключительно карьерные грузовики грузоподьемностью от 400 тонн?
Аналогия прозрачна?
1с очень неудачно выступили в области erp, это факт. Однако большинству производств, не ведущим попередельный учет, а работающим с со спецификациями и черным ящиком, она нафиг не упала яУТ или УНФ за глаза.
А насчет ПОЯ, скорость разработки и доступность специалистов на стороне 1С. За 4 часа можно накидать полноценный учетный контур. С документами, отчетами, печатными формами и т.п. на каком языке можно получить такую скорость разработки при сопоставимом качестве?
Для малого и среднего бизнеса альтернативы все еще дороже и хуже. Для микробизнеса альтернатив уже полно
Вы не поверите, но даже малый бизнес сейчас интересуется прогнозированием и оптимизацией, так как стоимость средств для них стала доступна даже для ИП. Тогда как 1С остается лишь учетной системой с закрытой структурой БД, которая не позволяет использовать подобные решения в непрерывном режиме.
Я так понимаю что про прямые запросы, Вы не слышали? Про 1С++?
Скажите, а насколько вы знакомы с темой? Для меня 1с - это интерпретируемый предметно ориентированный язык, со своими плюсами и минусами.
ЗЫ и что такое прогнозирование и оптимизация можете раскрыть? Упомянутые в данном ключе именно
Вот только мир намного разнообразней, чем 1С. И на рынке есть множество решений, в том числе и open source, замечательно адаптируемых к любой БД, поддерживающей SQL язык запросов.
Я так понял, что вы предлагаете эти решения переписывать на 1С++? А за чей счёт банкет?
Про прогнозирование и оптимизацию можете сами почитать, так как это явно выходит за рамки комментариев и достойно целой серии статей.
Упрощенно, даже владелец фруктового ларька хочет знать сколько, по какой цене и с какими сроками поставки нужно заказывать фруктов, чтобы и весь ассортимент был в наличии, и фрукты не успевали испортиться и прибыль была максимальной.
Я предлагаю? В каком месте? Я предлагал использовать инструмент соответствующий задаче. И в моем ит ландшафте для 1с есть место.
То есть вы даже не можете сформулировать что имели ввиду под прогнозированием и оптимизацией, но при этом уверены что 1с в такое не умеет?
Я уверен, что в 1С нет огромного количества решений имеющихся на рынке. И напрямую к БД 1С эти решения не подключить
Наверняка. Скажите, у вас в детстве был велосипед? Вы переживали из за того что к нему нельзя подключить гидромолот, бульдозерный отвал или ричтрак?
Есть огромное количество вещей где 1с проиграет всухую крнкурентам. Но в своей нише они лучшие. И сковырнуть их оттуда пытаются больше 30 лет
Вы переживали из за того что к нему нельзя подключить гидромолот, бульдозерный отвал или ричтрак?
А сейчас переживают, если к велосипеду нельзя подключить двигатель с аккумулятором.
Времена меняются. Еще десять лет назад никто на домашнем компьютере AI не обучал, а сейчас - пожалуйста. Еще десять лет назад владелец фруктового ларька ездил на базу к одному поставщику, а теперь заказывает на онлайн площадках у сотен поставщиков.
"напрямую к БД 1С эти решения не подключить" - это не значит, что нельзя подключить.
Например, у меня есть open source решение, позволяющее принимать решение за 50 мс. 95 процентиль должен укладываться в 100 мс после сохранения операции в БД. Как Вы это решение подключите к 1С?
Точно так же как к любому другому. При помощи механизмов интеграции.
А вот вопрос, какому количеству пользователей нужно уложиться в 50мс на такте в 95 процентах?
Вот и расскажите мне, какой механизм интеграции в 1С обеспечит указанную задержку.
Вопрос о пользователях не ясен, так как речь идет о состоянии всей системы.
Вы себе вбили в голову, что 1с это учетная система, причем жестко приколоченная. А это не так. Это язык. На котором, пример из опыта, можно писать даже микросервисы, со скоростью отклика менее 10 мс
Это язык.
О да! Можно даже написать COM объект и дергать его в своё удовольствие. Но из-за этого стоимость интеграции оказывается дороже лицензии на всю 1С.
Ну или реализовывать gRPC через nodejs )))
Что такое "Система 1С"?
У 1с больше 1 млн установок. Какой доле этих систем нужно время отклика 50мс?
Есть ТрадиционныйКитайскийВопрос™ - анахуа?
1с не предназначена для управления технологическими процессами. А для владельца ларька даже 10 минут некритичны.
Вы с мелкооптовыми электронными площадками никогда не сталкивались? Там лот мандаринов на привлекательных условиях может улететь за минуту.
с мелкооптовыми - нет. И для большинства ларечников даже excel - это слишком сложно. И этим "улетевшим за минуту лотом" вся сеть его ларьков теоретически сможет торговать ближайшую пятилетку (если не учитывать, что они прокиснут). вы еще скажите, что ларечник будет выстраивать цепочки поставок...
И для большинства ларечников
Ого! Ознакомьте меня с источником столько интересной статистики. А то сколько у моей жены, подрабатывающей на дому главбухом, клиентов, владельцев ларьков, так почти все хотят автоматизации закупки на площадках.
Потому что вручную фиг сообразишь, стоит ли этот лот покупать по данной цене и с данным сроком поставки, или он сгниет, прежде чем его получится продать.
вы еще скажите, что ларечник будет выстраивать цепочки поставок...
Решая что и когда покупать на электронной площадке, он, по сути, уже это делает )
Хм, у нас похоже разный опыт. Возможно в москве есть аналог товарной биржи. Но есть всякие Наполке, прямые контракты с поставщиками и дистрибами. Там нет гонки за покупкой лота
Ну вот у нас из активных 2132контрагентов - 1788 ИПшников. (вот прямо сейчас сделал запрос к базе) Из них ларьков - примерно 1100-1300. Из этих ларьков - значительную часть (в районе половины) не можем вынудить оформить площадки Меркурия, включиться в ЭДО для ЧЗ. Поэтому вынуждены торговать с ними как с "физиками" (после принятия такого решения - сейчас на такие отгрузки переведено пока 328, с начала марта, остальные в процессе) Т.е. у них просто нет ни компьютера для работы, ни учетной системы вообще. все по формуле маркса "товар-деньги-навар".
Я сталкивался с управлением непрерывным производством, с подачей сырья по сети трубороводов. Со средним временем реакции управляющего воздействия на изменение данных датчиков около 6мс. И да, морда вся была на 1с. Что я делал не так?
И да, морда вся была на 1с.
Так то - морда. А вообще, 1с на это не расчитывалась. Хотя на ней и биллинг то-ли опсосов, то-ли провайлеров локальных пейсали. я асссемблер-реассемблер пейсал. Но это не значит, что так нужно делать.
Что я делал не так?
Непрерывная балансировка и оптимизация ресурсов предприятия - это совсем не управление непрерывным производством.
Еще раз: 1с это язык, на котором написано множество програмных продуктов. Включая ERP. При этом именно ЕРП у 1с получилась очень неудачной. При этом вы осуждаете язык, за то что конкретный продукт не умеет в балансировку. Тогда заодно и плюсы осуждайте, именно на них 1с написан
Я не осуждаю язык. Я указываю, что огромная масса существующих драйверов, коннекторов, библиотек, препроцессоров и т.п. поддерживает языки общего назначения, но не язык 1С. А писать свои средства на все невозможно, нерентабельно и все равно будешь всегда роли догоняющего. Именно поэтому SAP активно уходит от ABAP к JAVA, а MS уже ушел от X++ к C#.
C++ тоже осуждаю за фактическое отсутствие стандарта ABI. Что, собственно говоря, и привело к необходимости изобретать свои костыли в разных системах.
Я так понял, что вы предлагаете эти решения переписывать на 1С++? А за чей счёт банкет?
А писать свою учетную систему - бесплатно? Никто не запрещает любому владельцу любого ларька использовать любую учетную систему - от блокнота до SAPа.
И на рынке есть множество решений, в том числе и open source, замечательно адаптируемых к любой БД, поддерживающей SQL язык запросов.
своего рода "неуловимых Джо"? типа пресловутой фузины?
даже владелец фруктового ларька хочет знать сколько, по какой цене и с какими сроками поставки нужно заказывать фруктов, чтобы и весь ассортимент был в наличии, и фрукты не успевали испортиться и прибыль была максимальной.
хотеть-то он может. Есть ли системы, способные это посчитать (в т.ч. эластичность спроса), и доступные этому хозяину ларька (в т.ч. и по цене)?
Он не слышал и про 1с.Аналитику, да и про возможности анализа внутри 1с...
1с++ - это все-таки отдельная тема, да и нынешним лиц.соглашением (учед вендор появление 1с++, только, хм, своеобразно) доступ к данным напрямую запрещен. Но если хочется, то есть ПолучитьСтруктуруХранения, да и OData
Самое главное - зачем это надо. Никто не мешает тяжелые расчеты вытащить в другие технологии. Миллион продуктов на рынке, где на 1с формошлепство и процессное управление. А сами процессы на расте и скуле. Или более того на 1с только миддлварь, а фронт на реакте, бэк на какой нибудь графовой ереси вроде арангоДБ
Прочитайте определение ERP. А теперь скажите, Вы понимаете разницу между непрерывной и оффлайн балансировкой и оптимизацией ресурсов?
Скажите, вы правда не понимаете, что ерп не нужна 95% пользователей 1с?
Зы О! балансировка и оптимизация ресурсов оказывается. Клещами тащить приходится. Ресурсов сервера или речь про управлениеипрограммой производства? Речь не про ПО, а про производственную логистику и управление этапами
за 50 мс нужно решить, что раз станок №5 встал в аварию, то нужно срочно изменить поставку сырья на дату+2 недели вперед с 1 вагона на 0.975 вагона... иначе никак. оптимальность разбалансируется, и трындец...
почитаешь тут на хабре истории, скажем, от НЛМК - они ж тогда вообще должны были разориться, сгореть, обанкротиться и взорваться одновременно, ведь не успевали оптимизировать балансировку за 50 мс
Изучите хотя бы область, которую взялись обсуждать. В рамках комментариев обучать человека концепциям ERP не реально
Изучите область, которую взялись обсуждать. Не нужно перекладывать опыт взаимодействия с одним конкретным прикладным решением на язык вообще, и другие решения написанные на этом языке в частности
При чем тут язык, если обсуждается концепция управления хозяйственной деятельностью и соответствие этой концепции программных систем?
Если 1С сделает в платформе полноценную поддержу D-Bus, gRCP, Kafka, RabbitMQ, Redis, Cassandra и т.п. - проблемы исчезнут.
И вот тут уже возвращаемся к языку, так как для этого надо переписывать на язык 1С целую гору рабочего и постоянно развивающегося open source, да еще и постоянно переносить изменения, появляющиеся в нем. А вот это уже проблема. Потому что это бесконечный процесс. И если для массы других языков драйвера/коннекторы есть из коробки, то для 1C приходится каждый раз изобретать велосипед.
SAP, обнаружив это, начал активно продвигать на замену ABAP Java. MS отказался от X++ в пользу C#. А 1С держится за своё легаси.
все эти брокеры нужны нагруженным системам. а таковых очень немного, и обслуживаются толковыми людьми. Которые взаимодествие с брокерами реализуют сами, по потребности. Тут не так давно целая разгормная статья была, что и так дофига в 1с понавпихивали. а вы еще предлагаете навпихать...
Я наоборот, призываю перейти на язык, для которого все эти драйвера, коннекторы, библиотеки, препроцессоры и генераторы кода уже есть, поддерживаются, развиваются и появляются новые. И не надо будет ничего впихивать.
Язык-языком, а кто на этом языке всё напишет, стандартизирует, организует дистрибуцию решений, поддержку, обновление вслед за нашим ВзбесившимсяПринтером, и т.д.
На данный момент наибольшие компетенции и возможности для этого именно у 1С. Но со временем это может измениться.
SAP до сих пор от ABAP не избавился, что не мешает ему почти все новые разработки вести на Java
Для Кафки есть внешняя компонента, работающая в 1С. Гоняем через неё в районе 10 млн сообщений в день, полёт нормальный :) Но если бы была в 1С нативная поддержка - было бы лучше, конечно :)
Если бы она была родная, то и сопровождать её пришлось бы 1С. Кафка - развивающийся продукт.
А теперь расскажите, как эту внешнюю компоненту прикрутить под Linux. Не будете же Вы платить по 300 тыс. штрафов, обрабатывая персональные данные на Windows?
Никаких проблем, пишете ВК под линукс с использованием NativeAPI, прикручиваете к 1С под линукс и вот вам счастье.
https://habr.com/ru/articles/666718/ - статья на хабре, как это делать.
https://infostart.ru/1c/tools/1979776/ - еще пример, ВК, работающая и под виндой, и под линуксом.
1С Шина. Я не про производительность и прочие "плюшки", я про то, что в принципе она есть.
1С Аналитика не позволяет производить балансировку непрерывно
Балансировку чего?
Главная задача ERP - непрерывная балансировка и оптимизация ресурсов предприятия. Странно, что Вы не знаете определения.
Странно что вы считаете 1с ерп системой. С чего вдруг 1С розница должна заниматься балансировкой ресурсов? Или MES система, или документооборот.
Хотя бы для того, чтобы прогнозировать спрос и на основе этого планировать закупки. Заметьте, что это востребовано даже у ларька.
Розница должна торговать, МЕС управлять производством, документооборот обеспечивать управление администрированием предприятия. Ни одна из описаных систем не должна заниматься ничем подрбным. За попытку всунуть аналитику во фронт или миддлофисе руки надо отрубать по самую жопу, откуда они растут.
Прогнозирование торчит в бэкоффисе, то есть, к примеру, в УТ есть свой блок, который примерно подходит для продуктов, но слабо подходит для фармы или радиокомпонентов. Поэтому есть отраслевые решения, да и прицепить алгоритмические или нейросетевые блоки предиктивного анализа ничто не мешает.
Какая разница, кто административно отвечает за прогнозирование, балансировку и оптимизацию ресурсов предприятия? Для того, чтобы это происходило непрерывно, эти модули должны быть интегрированы в приложение с задержками миллисекунды, что 1С на данный момент позволяет только через разработку COM компонентов и, само собой, исключительно под Windows.
Тогда как подобные модули уже имеют поддержку целого ряда языков общего назначения из коробки. Причем эта поддержка поддерживается и развивается
1С:Аналитика - это замена PowerBI и прочим Tableau, она в принципе ничего балансировать не может.
А в чем предметно-ориентированность 1с заключается? За 4.5 года что на 1с писал я так ее и не увидел. Увидел только убогий процедурный язык с динамической типизацией откуда то из 80х. Все бизнес сущности предоставляются фреймворком, в языке ничего относящегося к бизнес домену нет.
К 1с есть много вопросов, но из статьи создается впечатление что автора главным образом не устраивает что это не написано на чем то модном и современном.
Пример с нокия очень показателен.
Я тут крамольную мысль выскажу, но нормальному бухгалтеру 1С не нужна. По сути это программистский взгляд на бухгалтерию, никто не удосужился пойти в народ, посмотреть как они жили до 1С, спросить чего не хватает. У меня есть и айтишное и финансовое образование и то что делается установкой огромного комбайна по большей части избыточно. Формы легко ваяются в том же ворде, данные можно хранить в обычной ODBC базе и забирать оттуда скриптами. Баланс сводится на коленке в экселе, а если нет денег то в ОпенОффисе или даже гугл шитс.
Когда всё делают за тебя извилины в мозгу разглаживаются и ты забываешь предметную область. И в конечном итоге теряешь деньги - и потому что комбайн дорогущий, и потому что есть тонкости о которых 1С не знает.
Она не крамольная. Скорее невежественная. С чего вдруг возникла мысль что у бухгалтера не спрашивали? Или предположение что 1с проросла в вакууме? Это результат кровавого естественного отбора. Как белый медведь - вершина пищевой цепочки северной суши.
У меня тоже финансовое и айти образование. Только я застал еще бухгалтерию на бумаге, миллион поограмм под дос, 1с 6.0 которая продвинутый эксель по сути и т.д.
И еще сотни попыток написать свое. Написать не сложно. Обеспечить поддержку и оперативное изменение вместе с законодательством, вот где проблема. А потом еще стоимость владения, зоопарк или унификация и т.д и т.п.
1с - это обычный инструмент, и не более того. Но это инструмент не только бухгалтера.
посмотреть как они жили до 1С, спросить чего не хватает.
До 1с (и вместе с 1с) было много чего. и 1с победила именно потому, что предоставляла больше того, что нужно, нежели другие.
Формы легко ваяются в том же ворде, данные можно хранить в обычной ODBC базе и забирать оттуда скриптами. Баланс сводится на коленке в экселе, а если нет денег то в ОпенОффисе или даже гугл шитс.
Ну так никто не заставляет вести учет в 1с. Просто все эти "формы в ворде" уже нарисованы за вас, регулярно обновляются, "скрипты" написаны... а баланс можно свести и вообще без компьютера...
Когда всё делают за тебя извилины в мозгу разглаживаются
И вы, чтоб не делали за вас, написали свой аналог ворда для рисования форм, свою БД, и свой интепретатор собственноручно придуманного скриптового языка?
и то что делается установкой огромного комбайна по большей части избыточно
Отправлять данные по ЭДО гораздо удобнее из 1с, чем из веб-морды. Всякие ГИСы тоже лучше обрабатывать там же, где ведется и основная деятельность по учету. "огромность комбайна" обусловлена универсальностью применения - кому-то достаточно простого учета по УСН, у кого-то на УСН накатини НДС, у кого-то алкоголь, и , следовательно,ЕГАИС, у кого-то бензин и акцизы, у кого-то подконтрольная продукция меркурию, честному знаку, всем этим сатурнам, шубоисам, зерно и прочие творения горячечного бреда госорганов... в 1с есть всё это, поэтому монстр
Что я сейчас прочитал?
1C - это надстройка над RDB, которая делает "проводки". Если 1С тормозит, это тормозит база. Остальное всё - примерно то же, что в любой системе. Ну да, язык немного специфический...
Ну и комментарии не-бухгалтеров доставляют.
Ага, особенно смешно смотреть как эта "надстройка" работает с торговым оборудованием вроде весов, принтеров и.т.п. Даже банальная задача "выгрузить список наименований из реестра сведений Товары на ККМ" решается так максимально криво и обязательно (sic) в 1 (ОДИН) поток. Поставл пользователь "выгрузку" и пошёл обедать, вернулся, а обработка ещё выгружает. И метким запросом одноэссник в любой момент может заставить платформу сформировать такой запрос нокаутирующий базу(и ладно если дело у них заканчивается падением рабочего процесса и десятком взбешённых пользователей!). Это уникальное достижение 1С по-моему. Вот такие "не-бухгалтерские" наблюдения.
никакого заказа "сверху" не было. Тогда все клепали бухсистемы. Валом. сделанной хоть на коленке хоть на кларионе, dbase, паскале и прочего самописа.
Самопал на предприятии и в любой конторе, делали все - но тоже тупик тупиковый.
И все уперлись в одно - трудность конфигурации, развития и понимания, после того как разработчик ушел. Отсутствие актуальных апдейтов. Бизнесу не годилось. Кода - нет, правки нет.
На чем 1c и взлетела - покрывая потребности и гарантируя функционал и единообразность, модифицируемость под конкретное и оперативно обновляя нужные формы документов.
И понимание бухгалтера, как этим пользоваться а не учиться каждый раз сменив работу или "программиста".
а какой там язык - да пофигу. современная она или нет - пофигу.
чел просто не видел американские системы peachtree, квикены прочие мелкие -их было мильон.
При том, что американский учет для небольшого-среднего бизнеса не формализован, отчетности формальной нет, только налоговая форма, и прост как палка.
Интеграция и модификация - вообще дичь.
И да, подобное в штатах, но много хуже, с произвольным макроязыком какой сумели воткнуть (часто ранняя версия бейсика для встроенных приложений, чтоб не думать). Причем на уровне крупных инвестиционных фондов и банков (Russell, Barclays Chase). Вы этого не хотите - настолько коряво.
Больше скажу - самая крупная система для автодилеров в штатах (их было две с половиной на всю страну) по заказу запчастей и ремонту, - была (не знаю как сейчас, но не удивлюсь что да) на adabas, даже не SQL, а то, что было задолго до, помесь прадедушки баз неандертальца с операционкой начала зари компьютеров. С текстовым интерфейсом на TTY терминале. Чтоб с нее взять данные - надо было снимать скриншот экрана перехватывая данные по компорту.
но там - запчасти всех крупных американских производителей и расценки мегадилеров. И все- без вариантов. Потуги сделать на оракле не так чтоб были востребованы,бо что старая отлажена и работает. И никому нахрен не надо в 10 раз дороже. Работает - и ладно.
. С текстовым интерфейсом на TTY терминале
Они раньше начали автоматизироваться. Поэтому погрязли в легаси. В данном случае - в "железном"
Ашан до сих пор живет на коболе и ibm360. Но там собственнику за 80, и он неприемлет перемены
Мудрый человек. IRS тоже на коболе.
Просто он понимает, что переписать все на что-то другое - это только затраты. Прибыль от этого не увеличится. Сам по себе COBOL как "числодробилка" для коммерческих расчетов весьма эффективен. Просто он глубоко нишевый, соответственно и не сверкает в топах всяких модных опросов.
Как монахи переписывают одни и те же скрипты десятилетиями. Ибо не хватает ни времени, ни мозгов для того, чтобы создать нечто большее.
А монахи здесь причем? За язычком следи, подбирая аналогии.
Я ни разу не адепт 1С, и не ее хейтер. Я от этого мира далек бесконечно. А вот насчет кота - по моему мнению, пусть он лучше по многолетней привычке гадит в ванную, нежели я буду сталкиваться с передовой контейнеризацией в своих ботинках...
>Огромное техническое отставание. Где Git? Где нормальная отладка? Где тесты, >докеризация, CI? У 1С-шников вместо CI — курьер с флешкой.
Git есть. Сам наблюдал. И интеграция в 1C EDT с ним есть. Если мы конечно о серьёзной разработке говорим, а не о том, что бы в малом бизнесе за пол часа поправить отчёт в конфигурации
Докер- является удобным инструментом, но не является ни необходимым ни оптимальных инструментом для большое части решений.
CI- есть. Даже общался по работе (как админ) с devops 1С. Траблшутили вместе проблемы с производительность при работе с огромной конфигурацией
"все отчёты в 1С" как причина успеха- хм. Это вы как разработчик должны воспроизвести необходимые бизнесу ( в т ч и по регуляторным причинам) отчёты. А не делать их как Вам кажется красивым.
В 90тые кстати было несколько конкурирующих решений. Некоторые даже до сих пор живы. На вскидку- бэст и парус. и 1с выиграла. И продолжает выигрывать. Сами пишите -западные решения как крыло от боинга. Дак это плюс ведь в стороны 1С- что она давала и дает богатый функционал за куда меньшие деньги
Сам выбирал не однократно решения на 1С. Исходя из критериев гибкости и контроля за стоимостью владения системой. Хочешь -идешь к разрабам конфигурации. Хочешь -к 1С франчайзи. Хочешь- по ГПХ берешь разработчиков. Или в штат. С большей частью решений такое не выйдет- вендор лок. Хочешь доработок- плати сколько скажут.
Что не знают о ней зарубежом- и что? Думайте о релокации -выбирайте популярные в стране куда собираетесь технологии. Думайте о том, что бы жить в России- выбирайте востребованный здесь стэк. В России 1С это чуть ли не самый востребованный продукт. 1С разрабов куда больше чем, скажем на C++. причем даже в провинциальных городах. c#,с++ или java разработчики в сколько компаниях нужны? тем более какой нибудь ruby? или корпорации со своими отделами разработки. Или софтверные компании. А вот допилить 1С под бизнес процессы и хотелки компании- это задача почти в любом среднем бизнесе есть. А иногда- и в малом
Не хочу оставаться в стороне. Особо адептом секты не являюсь, наверное согласен с некоторыми историями:
Пропиетарный закрытый язык.
Да. Современный мир этого не прощает, особого смысла в своём языке сейчас уже нет (несомненно во временна C++ он был). Это тормозит развитие и новые кадры. Сложновато с нейросетями и IDE сейчас. Хорошая практика от него избавляться, а не изобретать новый ещё один, кстати :)
2. Замкнутость внутри СНГ
Многим стало актуально - тоже значительный минус конечно. Следствие (1)
3. Зависимость от компании 1С
Это тоже в современном мире конечно большой минус. Но опять же следствие (1).
В остальном написана бредятина конечно:
Методология наше всё. Поэтому внутри SAP ещё код с 70-х крутится
GIT\CI паттерны и практики конечно все в 1С есть. По сути разработка ничем особым не отличается от классической. Ну для нормальных команд конечно
Микросервисы решают вполне определенные задачи когда много команд разработчиков делают один продукт с детальным вниманием к каждой фиче. Для ERP этот архитектурный паттерн никак не подходит. Тем боле тут ещё ACID а не BASE - удачи в микросервисах. Как и контейнерах - это не панацея, а функционал который рождает продукт
Я видел кучу критиков 1с которые доказывали что 1с это отстой. Так же видел немало крутых программистов которые били себя пяткой в грудь, заявляли что они за неделю напишут программу лучше чем 1с. И все эти несостоявшиеся "убийцы 1с" быстро сдувались .
Все знают про недостатки 1с. Но забывают про достоинства.
Популярность.
Поддержка
Главное в 1с, это популярность - все пользователи умеют работать с 1с, нужен специалист по 1с - плюнь в толпу и попадешь в одинэсника, потому что их тысячи. У всех контрагентов стоит 1с.
Так же поддержка - все изменения в законодательстве отслеживают разработчики и вносят необходимые изменения.
Вот это главное!
Можно написать классную удобную быструю программу но если вы не обучите тысячи пользователей и специалистов - она никому не нужна.
Легче мирится с недостатками 1с, чем бегать и искать пользователей которые умеют работать на никому не известной и не популярной системе, искать специалистов, и держать команду разработчиков которые будут следить за законодательством и вносить изменения.
Поэтому основная проблема не написать программу лучше 1с - это не сложно. А вот сделать ее популярной это сложно. А пока не сделаете - она никому не нужна.
Легче мирится с недостатками 1с, чем бегать и искать пользователей которые умеют работать на никому не известной и не популярной системе, искать специалистов
Именно, помнится, в 2016 году мне отказали в трудоустройстве на логиста, потому что я сказал, что SAP в глаза не видел, но за неделю освою. Там требовались ТРИ транзакции (ну, и отчетики выгружать). А зарплата на SAP была в 2 раза больше моей.Я когда увидел этот SAP через неколько лет, и увидел эти три транзакции, а потом расковырял за пару недель как все устроено и даже автоматизировал кое-что на бейсике, так обидно было - из-за какой-то фигни я мог получать два года зарплату х2.
Сейчас ищу работу. Смотрю, у вакансии тонна откликов и просмотров если вопрос про 1С, а там где предполагается SAP, 3-5 просмотров.С одной стороны, с этой саповской махиной, где даже полный список транзакций в открытом доступе не выложен (те, кто видел полные - на самом деле не полные, напарывался), никто связываться не хочет, а с другой - ценник на того, кто захочет, все-таки повыше, даже сейчас, когда SAP свалил в светлое европейское будущее без России.Но желающих мало все равно - либо не знают, либо знают и не хотят связываться. Две недели наблюдаю грустную вакансию манагера на никому не известную систему учета на базе .NET. Беседовал с человеком, который поменял за 10 лет 8 складов - систему LEAD WMS он не видел ни разу и не подозревает что она существует (директор складского департамента, между прочим). Тоже висит вялая вакансия на управленца, который эту систему знает и хочет развивать :)
и держать команду разработчиков которые будут следить за законодательством и вносить изменения.
да ладно, тут к законодательству еще маркетплейсы добавились, в 1С уже видел типовые решения для маркетплейсов и фулфилмента, да и на коленке удавалось наколхозить, а как этот маркетплейс прикручивать к ERP в среде, для которой и разработчика-то фиг найдешь, а маркетплейсы требования меняют постоянно - это вообще беда.
У автора по моему психологическая травма, связанная с 1С...С руками из жопы пишется жопное ПО на любых языках - это факт. Да, есть свои минусы у 1С, но есть и однозначно плюсы. К чему эти рубрики гнева? Что есть идеальное ПО, которое проверено временем и работает, как часы? Или есть среди брыз гнева предложение?) Люди, пишущие такое, иногда платформу от конфигурации не могут отличить..поэтому рекомендую хейтить свои недопрогоаммы, коих по нашей Матушке колоссально огромное количество, и все также, как автор, пишет, чахнут над своим золотом, набрасывая говно на вентилятор другим сторонникам другого...
Человек, написавший этот опус, застрял где-то в нулевых и не в курсе, что вся разработка у вендора, включая CI/CD, давно уже ведется на гитлабе, а для тестирования используются и Docker, и Кубик, и много чего ещë. При этом вендор активно делится всеми наработками со своими "адептами". А недавно в средство разработки добавили ещë и очень недурственно работающего для первых релизов копилота. Автору матчасть подтянуть надо.
Где я это уже слышал ? " Да здравствует всемирная геволюция ! Долой капитализм ! Вся власть габочим и кгестьянам "
"Ах моська, знать она сильна..."
Народ, скажите, у нас что - криокапсула с адептом "напишем свой язык" откуда-то вывалилась? Ведь это уже давно было - только с языками.
Вспоминайте, как 10-12 лет назад, ту же Java ругали как только можно, совершенно игнорируя ключевые, важные для бизнеса фичи не столько самого языка, сколько поддержки и стиля развития. Каждый изучивший теорию компиляции/интерпретации делал своего убийцу джавы... С кучей синтаксического сахара, лямбда выражениями, и чем только нельзя...
Но вот - прошло 10 лет, джава есть, новых языков способных тягаться с джавай - нет. Потому что это очень дорогого стоит - не просто полностью описать внутреннюю модель языка, но и наладить тестирование и сертификацию на совместимость, обеспечить ~100% обратную совместимость. Но кто-ж это объяснит тем, кто кричит про архаичность, в погоне за синтаксическим сахаром ?
Вот и теперь. Дитё Человек воспитанный роботами модно-молодежными технологиями в упор не видит даже не армии методистов-архитекторов, создавших удобные и хорошо продуманные учётные механизмы (читай регистры. я очень хочу иметь такой же инструмент в джава - засунул туда измерения, накидал данные - а оно само посчитало остатки, движения, развернуло обороты и промежуточные срезы "буквально как только хочешь"... и olap тут во многих аспектах - рядом не стоял), механизмы отчётности (дайте мне такой же табличный шаблонизатор в java с визуальным редактором! я хочу просто клепать отчёты за полдня, а не это всё вытягивающее нервы-время-и-деньги тряхомудие с беком, рест-функциями, недопсевдомикросервисами, фронтом, джаваскрипт-библиотечками и семинаристками фронтендерами пилящими любой чих по полтора месяца...), систему метаданных с орм (хибернейт с jpa тут рядом не валялся потому, что не знает ничего про бизнес-сущности - документы и справочники с табличными частями)...
... вот не столько он не видит этого всего, сколько "не замечает" системы выпуска обновлений под постоянно меняющееся законодательство и налоговые требования, армии юристов и методистов это всё изучающими.
Это очень дорогого стоит - выпускать своевременно обновления под квартальную отчётность. И бизнесу важно ЭТО, а не "эти ваши кубернетиксы", открытые системы, и вся та чушь, написанная автором в разделе "почему это архаика" в статье выше.
Пожалуйста, изучайте вопрос, прежде чем делать такого рода выс... выбросы вбросы.
Если штука существует, существует долго, вопреки всему (как вам кажется), значит, как правило - что-то она делает правильно.
Давайте лучше винду все вместе поругаем, а? Ну реально же, больше толка будет))) Всем бобра.
Вы как то странно смешали в одну кучу язык программирования и методы классов. При этом при использовании стандартизированного ABI, D-Bus, gRPC и т.п. методы могут быть написаны на совершенно любом языке, а вызываться так же из любого языка. Что собственно говоря и позволяет не задумываясь и напрямую использовать в системе любые библиотеки, драйвера, коннекторы и т.п., поддерживающие общепринятые стандарты.
К слову - за 10 лет Kotlin вытеснил Java из ряда областей ;) Да, под капотом та же виртуальная машина, но язык то другой)
увы но это в основном андроид. и это не свойства языка.
андроид - область в которой есть 2 аспекта:
(1) гуглю нужен "запасной аэродром" от нападок оракула. Собственно, если бы не гуль, никому Котлин и даром не вздался бы. А гуглю Котлин нужен вовсе не из-за технических качеств языка. более того - см ниже - Котлин джаве не конкурент, потому что ... (см ниже)
(2) у андроид программ короткий жизненный цикл, завязанный на выпуск новых версий андроида (т.е. о переносимости старых программ на новый андроид речи не идет). а это значит я что ваша систему надо перерабатывать/дорабатывать/обновлять каждый раз как гуль сделает новый андроид.
а это означает, что системы на котлине Андроиде, не могут быть большими - точнее с ростом объема, затраты на их содержание растут, и как правило совсем не линейно.
и да, я напомню основные проблемы всех (само)убийц джавы: отсутствие спеки, тестов, альтернативных компиляторов. по этим признакам Котлин ничем не лучше всей той массы самописных язычков, толпами порождавшихся десять лет назад, и там же подохнувших на обочине истории. как только гуглю всбредет в голову что джава лучше, или ораул прекратит преследования за джаву - Котлин сдохнет. например как обджектив-си, будучи замеченный свифтом на яблоке. никому, как промышленный язык, обджектив-си не нужен. увы.
На андроиде котлин полностью заменил java. Да и на бекенде ява неслабо потеснилась для новых проектов. Собственно если бы они не поменяли модель развития и не снизили многословность за которые ее ругали, не добавили бы те самые лямбды и прочее - думаю она бы давно осталась в основном только как легаси. Как раз от старого стиля развития java давно ушла, современная уже не настолько кошмарна как была раньше (впрочем я бы ее все равно никогда для своих проектов не выбрал).
про вытеснение на Андроиде: см выше. это не свойства языка. Это результат политики/коммерческой деятельности Гугля. Котлин - это сейчас по факту - нишевый язык, аналогичный Свифту или Обджектив-си, который поддерживается исключительно усилиями платформодержателя.
Даже С#, как по факту, платфоменный язык для разработки под Виндоус, созданный после провальной попытки создать собственную несовместимую с основной спекой реалищацию java (юристы Sun знатно тогда поимели Майкрософт за J#), создаваемый на замену winApi+VC - он по факту более адекватен в этом плане (как универсальный промышленный язык выходящий за границы платформы и претендующий на создание бизнес-решений).
Про стиль джавы: новомодности в джаве, конечно придают популярности "среди молодежных движений", но повторюсь: они одни не способны вытянуть язык.
Вспоминайте историю последних 10 лет: ни одного "убийцы джавы" нет в живых, а джава есть. Может быть, у джавы есть что то более серьёзное чем модные фичи, лямбды и синтаксический сахар? что то касающееся подробного описания спецификации языка, тестирования на совместимость, наличие альтернативных совместимых компиляторов и обратную совместимость? читайте мой основной пост выше чтобы найти ответ.
Я хз про каких убийц джавы вы говорите. Очевидно что легаси проекты переписывать никто не будет. Впрочем, даже в них новая функциональность часто пишется на котлине. Я про бэкенд, если что, не про андроид сейчас. Можно же банально погуглить обсуждения людей. Вот как пример. https://www.reddit.com/r/SpringBoot/comments/16zsuod/spring_boot_with_kotlin/
Clarion
1C закапалась в сложностях, "наплодила сущности сверх необходимого".
Использование таких сложностей как EDT, Хранилище конфигураций, БСП - только усложнило жизнь программиста и ударило по карманам владельцев бизнеса. А возможно 1С специально это сделали для того, чтобы набить себе карманы.
Но если использовать расширение Внешний регламент для 1С (Внешние команды), то сопровождение, доработка и разработка на платформе 1С будет только в радость.
Я извиняюсь, а в чем проблема вообще написать приложение для бухгалтерии, есть же мой склад, котуры всякие, мое дело и тд и тп? Да и 1с переписать нормальным языком сохранив визуальный интерфейс проблема? Если уж разговор о привычках. Сколько людей и примерно столько и мнений о том что они хотят, но по факту нет решения - комбайна для предпринимателя. Мы вынуждены все что есть на рынке, сначала искать, потом как то скрещивать, тестить, опять скрещивать другие варианты, потом самые рабочие скрещивать с другими гибридами с помощью еще собственного кода заказанного на фрилансе или самописного и как то так это примерно работает. Ну и плюс к этому прикручивается гугл шитс со скриптами. 1с вообще странная и непонятная хератень которая по привычке нами юзается и никаких плюсов я не вижу в ней. А вот минусов полно, самый жирный это когда тебе надо переходить на серверную версию если база жирная!!! Нельзя менять остатки "на лету" ( сделайте галку если не нужны формальности для смены остатков) да еще вагон такой фигни.
разработчики используют самые современные инструменты и подходы, такие как облачные технологии, контейнеризация и микро-сервисы
Проиграл с такой "современности"
Периодически сталкиваюсь с администрирование 1с и для меня найти толкового конифугураторщикаразработчика та ещё головная боль, это не из-за того ж, что слабые курсы, а потому что люди, которые приходят - не той системы, они приходят говорить "во всём виноват предыдущий программист". Но когда они сталкиваются с реальностью, где нужно на форму навернуть логики - пишут тяп ляп и готово. Да, экосистемы закрытая, но с таким же успехом можно все банковские системы окунуть в тоже болота отчаяния. Проблема не в системе, а в людях, которые пишут эту систему, а ещё в государстве, которое за 3 месяца один регламент может поменять 6 раз. Да 1с стара, как мамонт, но это наш мамонт, с возможностями швейцарского ножа в вакууме космоса, не всегда понятно зачем, но как же приятно осознавать, что можешь управлять вселенной).
Как то имел опыт работы с разработчиком на 1с 77. Если что-то не работало, он говорил, что виноваты: железо, пользователи, админы, директор который дал не правильное ТЗ, всё остальные кого он не назвал, а так же сферический конь в шахте лифта застрявшего в пустоте черной дыры. И таких историй вагон при работе с 1с. Это показывает адекватность людей, которые приходят в технологию.
кажется плакать нет смысла, так как такие системы пишутся не ради красивого когда, их создают для выполнения бизнес-логики, которая облегчает жизнь, как оно написано - почти всегда вторично, главное чтобы отчёт показывал данные нужные менеджеру или отображал кнопочку в нужном месте. Самое главное приемущество - она из РФ, значит мы сделали самый важный проект для защиты интересов бизнеса и государство. Да, есть проблемы с механиками внутри, но эти проблемы катятся в глубокую бездну из-за маленького замечания: её не отключили после 2022 года, она развивается и даёт шанс бизнесу иметь вменяемую автоматизацию.
Ой, вроде всё)
Меня как сертифицированного когда-то специалиста по оперативному учету прям задела статья) Очень однобоко. Заезженное 1с-ник, пэхэпэшник и вот это всё. Отвечу тут. Продукт в своей нише заслуженно есть и остается по сути единственным выбором, а все проблемы и видение со стороны такое скорее от огромного количества пользователей, которые выбирают дешевого "1с-ника", а это очень собирательное название. Как "программист" (чего-то где-то в сферическом вакууме). 1С это не только (совсем не только) про бухгалтерию, а про автоматизацию учёта и не только в целом. Более того, если речь про предприятия и крупные компании, то и с кодом и с уровнем решения всё в порядке. 20 лет назад при разработке для внутренних нужд у нас был и стандарт кода и код-ревью и отдел тестирования и нормальный проектный менеджмент (это на 7.7 еще). БД отдельных баз 1С разворачивалась в OLAP для быстрого доступа через другие инструменты... Мне приходилось внедрять 8.1 на предприятии, приходилось автоматизировать магазинчики и супермаркет с нуля. Да, много дешевых студентов, но на больших проектах работают нормальные спеуиалисты, которые и не только "1с" и "отчетик подшаманить".
Говорят, что есть страны, где законы не меняются каждый день, где люди пользуются quickbooks и им больше ничего не нужно. Может не в программе дело ?
Чет ка кто много трамвайного яда с переходом к косвенным обзывалкам, не контекстно и похоже слепо взятых, с желтой прессы, для интересующихся домом-2.
Походу автор не сдал спеца по платформе и теперь токист на другой мир.
На самом деле в 1С с выходом БСП уже давно есть возможность использования микросервисов, в виде внешних обработок, для земны функционала по горячему не трогая «коробку».
Так же и с GIT 1C «научилась работать», с помощью конечно доп. функционала в виде OScript, Vanessa Autimation, VCS.
И не понятно зачем бухгалтеру осваивать «PostgreSQL, Python и нормальный UI.»? Чет автора как-то понесло на трибуне с надписью «я ненавижу 1С», туфлей постучал. ))
Встречал человека лет 6-7 назад, так он с командой 1С в Италии внедрял. Как я понял, за счет цены был спрос. А в остальном заказчиков вполне устраивало
Не хочу и не буду оскорблять чувств верующих в 1С. Это хорошая программа для своих целей. Целей сдачи бухгалтерской отчётности. Низкая стоимость коробки для 1-5 пользователей. Но дьявол кроется в деталях. Как только пользователей становится больше 50, а задачи, которые ставятся перед платформой выходят за рамки бухгалтерской отчетности ситуация меняется до наоборот И становится похожа на драку мокрым диваном. Программа предназначена для фиксации фактов хозяйственной деятельности через проведение документов для надёжности. Но для управления предприятием в режиме реального времени она не предназначена. Ну не сможете вы одновременно перепровести тысячи связанных документов. А если уровень вложений (связанности) превышает 3, то задача становится практически не подъемной. Да, находятся обходные маневры и решения, которые как правило носят костыльный характер, так как идут в разрез с принципами бухгалтерского учёта. А затем на костыли настраиваются новые костыли и так незаметно получается система, в которую вложены миллионы и содержание ее тоже стоит миллионы и десятки, а то и сотни бухгалтеров неустанно проводят документы. Зато работает скажете Вы и будете правы, да работает. Но первый, кто осмелиться разорвать эту порочную практику, автоматизировать что-то ещё, кроме бухгалтерской отчётности с помощью 1С тут же получит конкурентное преимущество и снижение себестоимости. Для сдачи отчётности нужен 1 бухгалтер, для ЗП ещё один, если людей много, все. Остальное можно и нужно автоматизировать иначе, исключительно из экономических и рыночных аргументов. Так дешевле и эффективней. Мы привыкли в обычной жизни готовить на плитке, стирать в стиральной машинке, мыться в душе и никак не наоборот. Почему же тогда с упорством носорога мы пытаемся автоматизировать бизнес с помощью платформы, которая была создана для других целей? При этом полностью игнорируя здравый смысл и забывая про цели. Для чего создаётся бизнес и для чего нужна автоматизация. Бизнес создаётся для извлечения прибыли, а автоматизация для оптимизации процессов и снижения себестоимости. В действительности же, получается, что автоматизация на 1С ограничивает эффективность бизнеса. И да, единороги существуют. Есть решения, которые могут эффективно решать вопросы автоматизации и интегрироваться с 1С для отчётности. Да, это не универсальные решения, но и одинаковых конфигураций 1С не существует. Давайте не будем ссориться, 1С существует и альтернативы существуют, а выбор за бизнесом, бизнес голосует рублем. Если решения на базе не 1С будут эффективней 1С, то через некоторое время 1С вернётся к своей первоначальной цели, а неэффективный бизнес исчезнет.
задачи, которые ставятся перед платформой выходят за рамки бухгалтерской отчетности ситуация меняется до наоборот [...] Ну не сможете вы одновременно перепровести тысячи связанных документов. А если уровень вложений (связанности) превышает 3, то задача становится практически не подъемной
а можно примеры?
Но первый, кто осмелиться [] автоматизировать что-то ещё, кроме бухгалтерской отчётности с помощью 1С
Ну, например, у людей еще на 7.7 работало управление роботизированными складскими тележками. 15 лет назад. У меня из 85 подключений - было 4 бухгалтера, остальные - как люди (всякие там менеджеры и кладовщики), так и всякие весовые посты, автоматы по выдаче сборочных заданий, и т.п. тоже более 10 лет назад.
А у меня BI дает остаток на каждый документ, при том ничего не хранит ни в каких регистрах кроме первичных записей и никакого перепроведения не требует. На лету высчитывает параметры на каждый день без хранения и их многочасовой записи их в регистрах, прям с таблиц первички. Я не знаю как оно это делает, но делает и голову мне ломать не надо что там под капотом.
А системы учетов документов могут строить последовательности взаимосвязанных доков последовательно, как они были в реальном времени внутри одной секунды, а не сортируя по типу дока по мере ввода в конфигуратор и объяснения клиенту что ну вот так вот.
И логирование информации на чтение.
И ведение учета без заднего числа прям из коробки методом ввода корриторовок в вседа текущем периоде.
И многое из этого на чистом 1С не повторить просто потому что это во первых интерпретатор, во вторых нет строгих типов, в третих потому что заточенность на универсализм быстрого внедрения и связанная с этим схема проецирования объектов на БД. И в четвертых заточенность именно на ведение бухгалтерского учета, а не системы управления реального времени.
И многое из этого на чистом 1С не повторить
ну так и не надо. BI прекрасно берет либо напрямую из базы, либо из витрин.
Я не знаю как оно это делает, но делает и голову мне ломать не надо что там под капотом.
Ну так узнайте. технологии предварительного расчета OLAP-кубов описаны давно.
И ведение учета без заднего числа прям из коробки методом ввода корриторовок в вседа текущем периоде.
Если это будут делать все и всегда - многие и 1с-ники, и главбухи будут рады. Но 1с когда-то "дала такую возможность", всем пользователям, на горе, понравилось - и теперь приходится с этим жить. Это не "недостаток 1с", а, скорее, декларируемое преимущество. которое многим осложняет жизнь. Но "пользователи привыкли", и если это запретить - будет вой.
учет доков "внутри секунды" - в клюшках было. видимо, посчитали, что особого смысла в этом нет. Честно говоря, даже не задумывался - не было задач, требующих такого.
И в четвертых заточенность именно на ведение бухгалтерского учета, а не системы управления реального времени
Да, именно, 1с не является системой реального времени. поэтому возлагать на нее такие задачи - идиотизм. впрочем, "там обрыв, но вам туда можно"©Альтов
Я уже указывал, что в современном мире, когда заказы у поставщиков производятся на электронных площадках, а движение вагонов и фур отслеживается в реальном времени, даже SCM превращается в систему реального времени.
Например, на одном из текущих проектов порой есть буквально секунды на создание накладной в ЭТРАН после определенных событий. Не успел - будет накладная от РЖД на отстой в какую то дыру, где локомотива ждать нужно будет неделю и которую всё равно потребуется оплачивать.
Если что, ж/д перевозки, беря вагон под управление по доверенности, заказывают даже ИП.
"буквально секунды" можно и на 1с сделать. Поднять отдельный инстанс (чтобы не зависеть от техокон основной учетной системы), слушать события и реагировать на них (пример - телеграм-боты). Если человек справляется с этим за секунды, то 1с точно успеет
"буквально секунды" можно и на 1с сделать
Каким солвером?
Если человек справляется с этим за секунды
Человек физически на такое не способен.
Каким солвером?
самописным
Ну вот у меня работают в 1с телеграм-боты. Отвечающие, например, по задолженности клиентов. Или выдающие клиентам ссылки на декларации соответствия и сертификаты, на ВСД, QR-коды СБП, информирующие о том, в какой точке находится сейчас доставляемый груз. Реакция - ну, пара секунд.
Не вижу, почему нельзя аналогично сформировать документ..
самописным
Дайте ссылку хотя бы на описание и результаты тестирования. Можно без дискретки.
Реакция - ну, пара секунд.
Вы вообще понимаете, что поиск оптимальной по финансовым критериями станции назначения для вагона и информирование об известном факте - совершенно разные задачи?
Дайте ссылку хотя бы на описание и результаты тестирования. Можно без дискретки.
Ну так поставьте нормально задачу. Из постановки я вижу - "создать документ в ответ на сигнал". Это реализуемо. А "высокочастотный трейдинг" на 1с реализовывать - такое себе (можно, конечно, используя 1с как шлюз - но нахрена тогда этот шлюз?)...
Опять же, если "поиск оптимальной по финансовым критериями станции назначения для вагона" - это настолько массовая и стандартная задача, что ее хочется реализовывать в 1с - то, видимо, есть 100500 других решений? можно примеры? а если не массовая - зачем ее пихать именно в учетную систему?
Ну так поставьте нормально задачу.
А я и поставил. Вместо накладной, сформированной РЖД в отстой на выбранную от балды станцию, вовремя сформировать накладную на отстой, погрузку или в ремонт на оптимальную станцию.
Неясно, как становится известно, что "РЖД сформировало", что значит "вовремя", что значит "оптимальную", критерии выбора, информация о доступных элементах выбора, критерии решения "на отстой, погрузку или в ремонт", конкурентности за ресурсы и т.п. Ну и, наконец, необходимость реализации этого для широкого круга пользователей в учетной системе
Читайте внимательней. Всю информацию по задаче я изложил. Подробности есть в нормативке.
Критерий, как и у любого бизнеса - максимальная прибыль.А так как адресация порожняка доходов не приносит - значит минимизация затрат. А уж куда адресовать, солвер и должен посчитать в зависимости от имеющихся и прогнозируемых заявок на перевозку, текущей и прогнозируемой дислокации остальных вагонов под управлением и технического состояния адресуемого вагона.
А пассаж про пользователей совсем не ясен. Системой пользуются все пользователи, в системе всё взаимосвязано, следовательно любая операция с подвижным парком в системе так или иначе касается всех пользователей.
Вагоны не только под управлением конкретного бизнес-пользователя. И свободными местами на станциях он не управляет - следовательно, эта информация должна приходить извне. Информация динамичная (не только эта контора отправляет вагоны, но и другие) - следовательно, она обновляется с какой-то периодичностью. Информация конкурентная (несколько контор могут выбрать одно "место", "парк", а его объем конечен), кто решает, как извещается об "отказе" и всё такое.
А пассаж про пользователей совсем не ясен.
Имеются ввиду бизнес-пользователи, бизнес-единицы, организации. Если это нужно 90% коммерческих организаций в стране - значит, должно быть 100500 готовых решений. Если это нужно 0.01% - нахрена пихать это в ученую систему?
любая операция с подвижным парком в системе так или иначе касается всех пользователей.
Сидит кладовщик, выдает метлы дворникам по заказам из УС. каким образом его коснется неподача вагона? как он об этом узнает, как он должен на это реагировать?
кто решает, как извещается об "отказе"
Я же написал - читайте нормативку! РЖД эту информацию не скрывает.
Решение принимается автоматически ЭТРАН. Кто успел сформировать накладную в пределах квот - того вагоны и примут в перевозку. Именно поэтому я и указал, что человек физически на такое не способен, так как будет проигрывать автоматическим системам.
следовательно, она обновляется с какой-то периодичностью
В ЭТРАН она изменяется в реальном времени. 10 мс назад квоты могли позволять данную операцию, а через 10 мс квоты могут оказаться исчерпаны.
каким образом его коснется неподача вагона?
Само-собой, сдвигом сроков поставки материальных ценностей. SCM касается всех.
хорошая постановка ТЗ - "читайте нормативку".
В ЭТРАН она изменяется в реальном времени. 10 мс назад квоты могли позволять данную операцию, а через 10 мс квоты могут оказаться исчерпаны.
т.е. даже автоматизированная система со стороны клиента не обладает реальной информацией... (пока она считает оптимум - ситуация изменяется)
Само-собой, сдвигом сроков поставки материальных ценностей.
его эти материальные ценности могут не коснуться. совсем. он будет более зависим от вчерашнего снегопада, нежели от задержки вагона.
В общем, ваш пример можно считать притянутым за уши...
хорошая постановка ТЗ - "читайте нормативку".
А с чего Вы решили, что заказчик приходит с ТЗ? ТЗ сами пишите и согласовывайте с заказчиком.
т.е. даже автоматизированная система со стороны клиента не обладает реальной информацией... (пока она считает оптимум - ситуация изменяется)
Естественно. Поэтому без прогнозирования тут никуда. В моем случае "телескоп" начинается с 15 минут и заканчивается тремя сутками.
его эти материальные ценности могут не коснуться. совсем. он будет более зависим от вчерашнего снегопада, нежели от задержки вагона.
Да нет, просто дворники уволятся и уйдут в ТСЖ, где не надо лопатами по 12 часов в сутки снег чистить, а можно управиться за несколько часов, в связи с постоянным наличием на складе запчастей, расходных материалов и ГСМ для снегоуборщиков.
Документ документу большая рознь, там же может быть пара тройка-тысяч позиций с кодами маркировки. Но тут соглашусь с Вами, в принципе можно болванку документа сделать без проводок за прям доли секунды, выгрузить в инетграцию, а всю последующую работу повесить на пост-обработку. Вопрос где 1С поплывет когда надо будет делать последовательности зависимых документов за эти секунды, где без проведения нельзя. И там можно выкрутится поотключав на первый проход всякие истории, регистрации в планах и вообще все лишнее, но себестоимость разработки такая глубина использования платформы повысит знатно и спеца на это надо будет искать не в первом и не во втором франче.
Честно говоря не понимаю, зачем писать о предмете, в котором ничего не понимаешь? Просто кликбейты собирать? Автор вообще не понимает что такое платформа 1С, не понимает её функционала, приводит примеры, которые лишь опровергают его слова.
Если по пунктам:
- "как эта архаика вообще дожила до наших дней? " - очень просто - платформу переписывали. по сути создавая с нуля несколько раз. То, что есть сейчас имеет мало общего с тем, что было 25 лет назад.
- "теперь воспаляется при любом упоминании нормального CI/CD ", "Огромное техническое отставание. Где Git? " - платформа 1С имеет встроенную, очень удобную систему контроля версий, намного более юзер вредли, чем Git
- "Где нормальная отладка?" - ну зачем еще раз расписываться в том, что не знаешь продукт? Есть там нормальная отладка.
- "Разработчики 1С — не программисты, а конфигурационные заклинатели." - миф родом из1990х. Язык программирования 1С, такой же процедурный алгоритмический язык, как и другие. Такие же циклы, условия, переменные. А меньше кода, потому что язык предметно ориентированный, заточен под решение учетных задач и чтобы сделать запись движений материалов и выборку их остатков у разработчика уходит в десятки раз меньше времени и кода. Отсюда неверное и следующее утверждение:
- "мы теряем миллиарды человеко-часов" - бред сивой кобылы. Я посмотрел как разработчики на Go пытаются решить задачу расчета остатков ГСМ на заданную дату - они потратили несколько дней на то, что в 1С реализовывается за час.
- "Собственный закрытый язык" - ну да, проприетарный язык, платформа должна как-то монетизироваться.
- "Полная зависимость от компании 1С" - у пользователей SAP/Axapta нет подобной зависимости?
- "Служители храма. Разработчики 1С — не программисты, а конфигурационные заклинатели. Их работа — поддерживать, а не создавать. Как монахи переписывают одни и те же скрипты десятилетиями. Ибо не хватает ни времени, ни мозгов для того, чтобы создать нечто большее." - Опять же автор не в курсе тысяч решений реализованных с нуля на 1С. Да, есть джуниоры, которые колонки раздвигают, но есть и корпорации, полностью работающие на 1С - их автоматизацией и занимаются умные люди.
- "Локальная цифровая резервация. За пределами СНГ про 1С никто не слышал. " - опять мимо. Зайдите на сайт компании 1Ci или посмотрите список партнеров 1С в мире. Это уже далеко не СНГ.
- "Госрегулирование " - это 1С адаптирована под налоговую отчетность
- "Лобби. Государство и крупный бизнес десятилетиями закупали именно это. " - а что они должны были закупать - SAP в 10 раз дороже?
- "Низкий порог входа. Для бухгалтера проще выучить 10 команд 1С, чем осваивать PostgreSQL, Python и нормальный UI. " - ну это вообще бред... каких 10 команд? Там нормальный UI - иконки и меню - бухгалтеру не надо учить никаких команд. Бухгалтер должен учёт вести, а не программировать на Python под PostgreSQL
В итоге, я так и не понял - что конкретно автор предлагает. В чем учёт вести то?
это просто констатация фактов
В статье нет никаких фактов, это просто набор домыслов. Автор даже не удосужился изучить возможности современной версии платформы. Есть уже в 1С и контейнеризация и git и работа с любой шиной. Надо тебе микросервисы - пили. Надо тебе молонит - пили. Есть и бесплатные лицензии разработчика, и мини-сервер не требующий лицензии. Т.е. автор оценивает продукт в его состоянии 15-20 летней давности.
Ребята, не пойму, что вы тут обсуждаете? Какой-то Дима Фантазер (Dima @FantasyDD) невесть откуда взявшийся (с 20 апреля) стряпает здесь свои статейки-провокации, а народ ведётся и ломает копья. Нежели такую отсебятину можно публиковать на Хабре?
Или это такая конкурентная борьба? Нашему фантазеру - знатоку истории 1С, надо бы знать, что таких наездов на уважаемую фирму было в её истории несчесть. И каждый раз от этого она только выигрывала.
Так будет и сейчас!
Юрий, прежде чем писать такие выводы о человеке, которого вы, как сами признаётесь, не знаете — стоило бы хотя бы прочитать его тексты полностью.
Dima @FantasyDD не призывает к "уничтожению 1С", не устраивает провокации ради хайпа. Он просто описывает свой личный взгляд на технические ограничения и эволюцию решений, с которыми сталкивался как разработчик. Да, критически. Да, остро. Но в этом и суть Хабра — обсуждать технологии, даже если это задевает чьи-то привычные убеждения.
Никто не мешает вам — или другим сторонникам 1С — написать свой разбор, свою точку зрения, с примерами, фактами и успехами. Это и будет настоящая конкуренция мнений, а не попытки дискредитировать автора только за то, что он появился "с 20 апреля".
.
К слову, ваши две статьи на Хабре пока имеют рейтинг -2 и +1. Может, дело не в «фантазёрах»?
Я согласен, что каждый может писать что он думает и возраст аккаунта значения не имеет. Но имхо, это не означает, что статья не провокация, т.к.
а) Никаких принципиально новых возражений против, отличных от других подобных статей, не было. Разбор не слишком глубокий и, если статья была нацелена на вызов обсуждения, то можно было просто зайти почитать те же сотни холиварных комментов под любой другой
б) Как и любая "острая" и "критическая" статья о технологии, спикер в которой носителем технологии не является, ничего "острого" и по настоящему колющего в ней нет. У 1С много проблем - о них знают 1Сники в первую очередь. Если бы я как 1Сник, написал статью о том, почему мне не нравится Go, то мне бы так карму спустили, что это было бы последнее из написанного на этом портале. И да, в первую очередь по резонной причине "Что 1Сник может знать про Go, на котором не пишет? Ваша статья очень плохая, вы ничего не понимаете в Go". 1С же, в свою очередь - бесконечный мальчик для битья. Любому программисту понятно по умолчанию - 1С не программирование и хорошим быть не может. Это настолько очевидно, что факт наличия подобных двойных стандартов - где наброс не-носителя на любую технологию осуждается, а на 1С поощряется - как-то уходит из виду. При этом реально сталкивались с ней не только лишь все, но очень немногие, из тех, кто ненавидит - про себя или вслух. Зато + в карму кинет каждый, а холивар обеспечен
в) Статья просто полна эмоций. Эмоций > фактов. Это просто не технический материал, а художественный, где фарс, мазюканье по верхам черными красками и клеймление всех критикующих (ну т.е. реально работающих с технологией, про которую идет речь, лол) сектантами, разбавляется изредка проблемами - иногда правдивыми, а иногда нет. Может кому-то нравится читать такое, когда речь идет о технологиях
" Их учат не мыслить, а следовать инструкциям "
" мы теряем миллиарды человеко-часов. Мы держим рынок в плену "
"и экзамены, напоминающие обряды посвящения. Ты не учишься программировать — ты постигаешь откровения. После получения сертификата тебя не поздравляют, тебе говорят: «Да пребудет с тобой конфигурация». "
Мне нет, думаю, я имею на это право
г) В моем понимании, материал написан в таком ключе, что 1Сник должен задуматься, каким ужасом он занимается, и резко стремительно перестать. Но опять же: любой 1Сник... Нет, даже не так: любой разработчик на <language name> знает про свой <language name> больше, чем тот, который на <language name> никогда не работал. Вопрос смерти 1С - в первую очередь вопрос бизнеса, а во вторую, собственно, 1С программистов. По-настоящему критические разборы настоящих проблем - вопрос профессиональных сообществ.
Сразу оговоримся, предвещая обязательный вопрос: нет, 1Сники - это не сектанты, как нравится говорить автору: несмотря на явное отставание, наша работа не в том, чтобы целый день сидеть и молится на ЛТЕ монитор с запущенной 1С:Бухгалтерия. У нас есть Jenkins, SQ, Git, фреймоврки тестирования, докер, есть свой локальный небольшой open-source. И, соответственно, "профессиональные сообщества", это не "общины централизованной религии", а такие же группы, как на других стеках, где (ужас) 1С критикуется, но, в отличии от этой стати, в целях решения проблем, а не холивара
Т.е. ситуация такова, что (и автор это признает) 1С никуда не денется, есть люди, которые работают в ней и обсуждают проблемы между собой. А есть эта статья
Что это, если не наброс и провокация?
Ну и по фактам немного, а то скажут, что я по сути не критикую ничего:
Никаких стандартов
Это неправда. Есть стандарты фирмы 1С, есть стандарты сообщества
никакого опенсорса
Ну, во-первых, сама постановка интересная: как связано отсустствие опенсорса и контроль со стороны фирмы 1С? Разве что, речь идет только про то, что опенсорсом не занимается сама фирма 1С. В последнем случае это правда (у них есть акк на Github, даже не совсем пустой, но не уровень), а в остальном нет. Опенсорс, да маленький, но дружный, а главное - он есть
Где Git?
Так уж исторически сложилось, что хранилище конфигурации - встроенная система контроля версий, вышла одновременно (вроде, чуть раньше) чем Git - поэтому изначально Git туда не попал. С другой - 1С не имеет "проектов" в файлах, как у других языков, отсюда танцы с бубном. Но даже так Git, конечно, есть: он есть в EDT, с утилитой от вендора, и с утилитой от сообщества
Где нормальная отладка?
Не знаю, что не так с отладкой: есть стек вызовов, есть брейкпоинты с условием, есть просмотр и изменение локальных значений. Ну, не говоря уже об базовых вещах, конечно. Но, возможно, я недостаточно программист, чтобы знать о чем-то еще
Где тесты, докеризация, CI? У 1С-шников вместо CI — курьер с флешкой.
Вот тесты: раз, два. Вот докеризация: раз, два, три. Вот CI: раз, два. Это не все, просто что в голову пришло
Разработчики 1С — не программисты, а конфигурационные заклинатели. Их работа — поддерживать, а не создавать. Как монахи переписывают одни и те же скрипты десятилетиями. Ибо не хватает ни времени, ни мозгов для того, чтобы создать нечто большее.
Как говорится: держи в курсе, Д'артаньян
Обучение 1С — это отдельная индустрия. Курсы сертифицированных жрецов, тайные знания «как правильно создать документ на платформе 8.3» и экзамены, напоминающие обряды посвящения.
Нету никаких жрецов и обрядов посвящения: есть сертификация от вендора, т.к. франчайз - там не учат, там сдают экзамены, типа как у Cisco. И есть просто курсы, как и везде
А с какими радостными лицами те, кто сдал экзамен, рассказывают, как они создали свой первый «документ» в системе. Да, это именно тот момент, когда 1С-шник чувствует себя немного волшебником, хоть и осознает, что его код — это не искусство, а просто Чистой воды магия.
Ну, это тоже фигня какая-то из больного воображения: что-откуда вытащено непонятно, создание документов это литрали Hello World, и кто там кому что рассказывает и какие экзамены для этого нужны известно только писавшему. Что касается джунов в принципе, то новый разработчик в 1С чувствует себя точно не более волшебником, чем разработчик на низкоуровневых языках, потому что одно дело бизнес-процесс из жизни описывать, а другое - указателями оперировать
И вот, когда вся эта машина продолжает работать, мы смотрим на современных программистов, пишущих на современных языках программирования, и это уже не просто смешно
Мой любимый вывод на эмоции из всего опуса: эти самые современные программисты, пишущие на современных языках, не то, что те, к которым мы на машине времени летаем в прошлое - буквально другие люди. Каждый первый язык в TIOBE не в периоде с 1995-2008 появились ведь, правильно. Сразу вот этот флер интересный, предствляется такой чувак, с кнопочным телефоном, а лучше с дисковым, и дискетами, обязательно дискетами) Может со мной что-то не так, это конечно имхо, и прямо из написанного не следует, но маневр пропагандистский такой очень удачный на мой взгляд
Программное чудовище, которое не должно было выжить или Что такое 1С на самом деле и зачем оно было создано