Реклама
Комментарии 34
Хорошая история, жизненная. Но уж слишком для мира 1С специфическая.
это как раз технические подробности в ней специфичны для 1С. а общий принцип встречается много где.

Да не только. Есть предприятия, где подобные циклы по непонятным требованиям, не только в 1С проходят, в 1С только выгружаются. Но тоже где-то между финдиром и главбухом источник требований. И проблема организационно решилась приказом по предприятию о новом способе округления, с учётом накопившиехся долей копеек ежедневно, а не в последний день. Ну и с технической стороны небольшими доработками и чистой

Это да, но архитектура и качество кода в типовых от 1С отдельно доставляют :))
«Это вам не типовая конфигурация от 1с, написанная квалифицированными программистами, под чутким присмотром опытных методистов, непрерывно поддерживаемая и хорошо задокументированная. В энтерпрайзном дермище ковыряться намного сложнее»©мизда

В том и дело, что не сарказм. В теме гневно клеймили джаву, и все такое…
Впрочем, вы, насколько помню, в мизде тоже бываете — должны знать тамошнюю публику.

Ну вот у меня пример вполне себе технической статьи лежит. И даже про 1с. Написанной правда чисто по фану, но техническая статья и не должна обязательно решать практическую задачу.
И даже еще одна статья чуть иного рода в планах. Даже тоже про 1с. Если быть точным про анализ одного способа интеграции с 1с с т.з. плюсов и минусов в разработке и поддержке для разных вариантов использования. Время бы еще найти свободное от работы и учебы.
Сияющие доспехи прямо на глазах покрываются тонкой плёнкой оксида мифрила…
Какая прекрасная иллюстрация к народной мудрости «держись подальше от начальства и поближе к кухне» и «инициатива наказуема»
Где тут технический уровень?

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


Тем не менее, и за такое — большое спасибо и плюс за статью! Это мое личное мнение, те кто против (и довольно активно минусуют), пусть не читают и не тратят свое время.

Можно для тех, кто не в теме, небольшой намёк на первоисточник аллюзии?

в последнее время в таких ситуациях очень помогает "тыц на картинку -> в контекстном меню "найти это изображение в %какой-поисковик-вы-используете%" :)

Поиск по картинке даёт матерный вариант фразы «ничего не понял, но интересно».

Одна из самых интересных статей на Хабре за последний месяц. Автор, продолжай

Сергей, а что именно вам понравилось в этой статье, чем она вам интересна? Вы на Хабре с октября 2017 года и за всё это время у вас в профиле есть одна закладка и вот этот коммент. Полагаю, что эта публикация — самое лучшее, что случилось с вами за два с половиной года на Хабре. Поделитесь, пожалуйста, чем именно вас зацепила эта публикация. Спасибо.

Не отвечу за feddorra, могу рассказать про себя. Статья мне понравилась тем, что хорошо иллюстрирует на примере истину, что не все проблемы решаются техническими методами. Более того, данная статья очень хорошо ложится в контексте обсуждения статьи «Нюансы современной медицины», в части лечения симптомов и глубины анализа при принятии решения о направлении лечения.
Я сам участвовал в подобном аттракционе. Краткая история — агентству недвижимости выгодно иметь постоянный поток клиентов, а риелтору выгодно иметь с этого потока денежку. Казалось бы цели совпадают, но тут возникает нюанс: риелтор может заработать на прямой продаже (приехал человек с чемоданом денег) или с помощью цепочек купли-продажи из нескольких участников (3-5-7). Прибыль конкретного риелтора отнесенная к потраченному времени, в обоих случаях, примерно одинакова, но есть существенная разница в трудозатратах. И риелторы начинают «сливать» клиентов (не заносить заявки в CRM), когда выясняют, что к ним обращается не вожделенный чемодан с деньгами. Поскольку кто обращение занес, тому в работу оно и назначалось. Потерю клиентов руководство пыталось решать техническими способами (уведомления во весь экран о входящей почте, записью и выборочной прослушкой всех звонков и пр. пр.). Сколько было потрачено денег и сил на внедрение всей этой автоматизации бардака, никому не известно. В итоге (с моей подачи) наняли 3-х сотрудников внешнего колл-центра, двое принимали весь входящий поток обращений (звонки и почта) и заносили его в CRM и им к з/п платили доп. бонус за количество внесенных заявок. Сформированная в CRM заявка по round-robin назначалась на произвольного риелтора. А третий человек обзванивал клиентов, которые отказались от услуг после общения с риелтором, уточнял и фиксировал причины отказа. Половина недешевой автоматизации стала не нужна, а выручка агентства значительно возросла с лихвой компенсируя з/п трех операторов.
Ну а техническим аспектом в моей истории бы являлось, что мы перевели в 2008 году все агенство, кроме бухгалтерии и топ-ов на линухи. Настроили перемещаемые профили, сделали доменную авторизацию, внедрили систему централизованного управления SpaceWalk и кучу разных полезных вещей. А потом до жилищки добрался кризис и «денежных мешков» не стало, и стали отказывать в ипотеке банки. И вроде город большой, люди рождаются, умирают, женятся, разводятся и клиенты в агентство пишут и звонят. А внутри агенства зарплату депонируют и оставшиеся деньги спускают в проекты по отслеживанию использования рабочего времени при работе на ПК, системы записи разговоров и прочие решения, не устраняющие причину болезни.
PS Ну а цимес ситуации был тот, что в этой компании я был простым админом.
Техническую статью можно было бы написать, если бы, например, вместо псевдопараллелизации удалось повысить производительности записи в базу (при условии, конечно, что причина низкой производительности не лежит совсем уж на поверхности). Какая-нибудь нетривиальная настройка базы, хитрая оптимизация запросов — в таком вот духе.

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

Ну и профессиональный уровень автора статей должен быть сильно выше среднего, иначе писать будет попросту не о чем: из задачи самой по себе можно только коротенькую заметочку сделать.
НЛО прилетело и опубликовало эту надпись здесь
Если прямолинейно отвечать на вопрос «на какому уровне писать статью», то всё просто: на каком уровне решали, про то и пишите. Очевидно, что любая задача может решаться на самых разных уровнях, часть их которых технические, а часть — условно «политические».

Статья, описывающая личный опыт — это case study, на который можно опереться. При этом хорошо, если в статье сказано, почему именно данный уровень был в итоге выбран, ведь это тоже существенная часть решения, которую читатель будет держать в голове. Хорошо, когда из статьи понятна суть подхода к стратегии, плюсы и минусы, результаты.

Некоторое фокусничество данной статьи состоит в том, что здесь описана проблема, полностью решающаяся на политическом, а не техническом уровне. Такое, конечно, случается, но в нормальных условиях вряд ли слишком часто. Если правильный ответ на любой вопрос — это «не делать вообще», то непонятно, чем в принципе вы занимаетесь и откуда деньги капают. Всё-таки в большинстве случаев политическое решение подразумевает техническую реализацию.
Автор малость не понимает суть бухгалтерии, хоть и не он один такой (а таких на самом деле большинство), но всё же надо как-то от этого избавляться.

1) Бухгалтерия — это отчётность перед врагами.
2) Отчётность перед друзьями называется «Управленческий учёт».
3) Есть ещё аудиторы, но уровень, на котором используется 1С, не предполагает серьёзной отчётности именно средствами бухучёта.

Следствием указанных пунктов является ненужность собственно бухгалтерского подхода для понимания показателей работы предприятия. Задача (главного) бухгалтера — минимизировать штрафы от врагов. Как он этого добьётся — зависит от его грамотности. В общем случае штрафы минимизируются показом левой отчётности, а вот как конкретно доказать врагам, что отчётность «не левая» — вот здесь действительно нужно творчество.

Отсюда вывод — бросать на бухгалтерию много людей, чаще всего означает передачу бухгалтерии функции управленческого учёта. Этого не понимают многие финансовые директора и им подобные начальники над главными бухгалтерами. Когда управленческий учёт ведётся бухгалтером — все данные, помимо необходимости быть обфусцированными для врагов, дополнительно искажаются разного рода бухгалтерскими взглядами на жизнь. В итоге отчётность становится непрозрачной. А фин.директор часто просто не знает, как может быть по другому, вот и терпит. Ну и вышестоящее начальство тоже терпит. И имеет мутное понимание своего собственного бизнеса. А в результате складывается ситуация вроде описанной в статье.

Я может глупость спрошу, и не совсем в тему статьи. Но нельзя ли операцию Map по настройкам распределения делать в течение месяца сразу после ввода первички, а в конце месяца выполнить чистое суммирование?

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


Я в своей жизни сталкивался с другим краевым случаем — адекватные бухгалтера и ретрограды в IT отделе. Забавно, что здесь ровным счетом наоборот (если верить автору).


С другой стороны, про миры. Автор описывает оптимизации базы… и кажется, что если бы управленка жила просто в отдельной postgres базе, то ее можно было бы получать чуть ли не в онлайн режиме при наличии вменямого DBA, причем одного хорошего специалиста бы хватило.


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

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.