Комментарии 34
Да не только. Есть предприятия, где подобные циклы по непонятным требованиям, не только в 1С проходят, в 1С только выгружаются. Но тоже где-то между финдиром и главбухом источник требований. И проблема организационно решилась приказом по предприятию о новом способе округления, с учётом накопившиехся долей копеек ежедневно, а не в последний день. Ну и с технической стороны небольшими доработками и чистой
И даже еще одна статья чуть иного рода в планах. Даже тоже про 1с. Если быть точным про анализ одного способа интеграции с 1с с т.з. плюсов и минусов в разработке и поддержке для разных вариантов использования. Время бы еще найти свободное от работы и учебы.
Уровень птичьего полетаи тут я проснулся.
Где тут технический уровень?
Так здесь его то и нет. Обычная слезливая быль, жизненная правда, Т.е. как раз соответствует используемому тегу "черт знает что".
Тем не менее, и за такое — большое спасибо и плюс за статью! Это мое личное мнение, те кто против (и довольно активно минусуют), пусть не читают и не тратят свое время.
Я просто оставлю это здесь:
можно :)
в последнее время в таких ситуациях очень помогает "тыц на картинку -> в контекстном меню "найти это изображение в %какой-поисковик-вы-используете%" :)
Вот оригинальный ролик, раз уж на Хабре этот мем не сильно известен.
Сергей, а что именно вам понравилось в этой статье, чем она вам интересна? Вы на Хабре с октября 2017 года и за всё это время у вас в профиле есть одна закладка и вот этот коммент. Полагаю, что эта публикация — самое лучшее, что случилось с вами за два с половиной года на Хабре. Поделитесь, пожалуйста, чем именно вас зацепила эта публикация. Спасибо.
Я сам участвовал в подобном аттракционе. Краткая история — агентству недвижимости выгодно иметь постоянный поток клиентов, а риелтору выгодно иметь с этого потока денежку. Казалось бы цели совпадают, но тут возникает нюанс: риелтор может заработать на прямой продаже (приехал человек с чемоданом денег) или с помощью цепочек купли-продажи из нескольких участников (3-5-7). Прибыль конкретного риелтора отнесенная к потраченному времени, в обоих случаях, примерно одинакова, но есть существенная разница в трудозатратах. И риелторы начинают «сливать» клиентов (не заносить заявки в CRM), когда выясняют, что к ним обращается не вожделенный чемодан с деньгами. Поскольку кто обращение занес, тому в работу оно и назначалось. Потерю клиентов руководство пыталось решать техническими способами (уведомления во весь экран о входящей почте, записью и выборочной прослушкой всех звонков и пр. пр.). Сколько было потрачено денег и сил на внедрение всей этой автоматизации бардака, никому не известно. В итоге (с моей подачи) наняли 3-х сотрудников внешнего колл-центра, двое принимали весь входящий поток обращений (звонки и почта) и заносили его в CRM и им к з/п платили доп. бонус за количество внесенных заявок. Сформированная в CRM заявка по round-robin назначалась на произвольного риелтора. А третий человек обзванивал клиентов, которые отказались от услуг после общения с риелтором, уточнял и фиксировал причины отказа. Половина недешевой автоматизации стала не нужна, а выручка агентства значительно возросла с лихвой компенсируя з/п трех операторов.
PS Ну а цимес ситуации был тот, что в этой компании я был простым админом.
Дело тут даже не в 1С — независимо от языка очень мало чисто практических задач потенциально могут быть материалом для мало-мальски интересной технической статьи. Причем с интересностью самой задачи это не коррелирует вообще никак.
Ну и профессиональный уровень автора статей должен быть сильно выше среднего, иначе писать будет попросту не о чем: из задачи самой по себе можно только коротенькую заметочку сделать.
Статья, описывающая личный опыт — это case study, на который можно опереться. При этом хорошо, если в статье сказано, почему именно данный уровень был в итоге выбран, ведь это тоже существенная часть решения, которую читатель будет держать в голове. Хорошо, когда из статьи понятна суть подхода к стратегии, плюсы и минусы, результаты.
Некоторое фокусничество данной статьи состоит в том, что здесь описана проблема, полностью решающаяся на политическом, а не техническом уровне. Такое, конечно, случается, но в нормальных условиях вряд ли слишком часто. Если правильный ответ на любой вопрос — это «не делать вообще», то непонятно, чем в принципе вы занимаетесь и откуда деньги капают. Всё-таки в большинстве случаев политическое решение подразумевает техническую реализацию.
1) Бухгалтерия — это отчётность перед врагами.
2) Отчётность перед друзьями называется «Управленческий учёт».
3) Есть ещё аудиторы, но уровень, на котором используется 1С, не предполагает серьёзной отчётности именно средствами бухучёта.
Следствием указанных пунктов является ненужность собственно бухгалтерского подхода для понимания показателей работы предприятия. Задача (главного) бухгалтера — минимизировать штрафы от врагов. Как он этого добьётся — зависит от его грамотности. В общем случае штрафы минимизируются показом левой отчётности, а вот как конкретно доказать врагам, что отчётность «не левая» — вот здесь действительно нужно творчество.
Отсюда вывод — бросать на бухгалтерию много людей, чаще всего означает передачу бухгалтерии функции управленческого учёта. Этого не понимают многие финансовые директора и им подобные начальники над главными бухгалтерами. Когда управленческий учёт ведётся бухгалтером — все данные, помимо необходимости быть обфусцированными для врагов, дополнительно искажаются разного рода бухгалтерскими взглядами на жизнь. В итоге отчётность становится непрозрачной. А фин.директор часто просто не знает, как может быть по другому, вот и терпит. Ну и вышестоящее начальство тоже терпит. И имеет мутное понимание своего собственного бизнеса. А в результате складывается ситуация вроде описанной в статье.
Я может глупость спрошу, и не совсем в тему статьи. Но нельзя ли операцию Map по настройкам распределения делать в течение месяца сразу после ввода первички, а в конце месяца выполнить чистое суммирование?
Если абстрагироваться от жизы и того, зачем делается отчетность, то автор большой молодец.
Пострадал за правду и не постеснялся поделиться жизой, а не сказками.
На Хабре такое уже редко встретишь.
Я в своей жизни сталкивался с другим краевым случаем — адекватные бухгалтера и ретрограды в IT отделе. Забавно, что здесь ровным счетом наоборот (если верить автору).
С другой стороны, про миры. Автор описывает оптимизации базы… и кажется, что если бы управленка жила просто в отдельной postgres базе, то ее можно было бы получать чуть ли не в онлайн режиме при наличии вменямого DBA, причем одного хорошего специалиста бы хватило.
Эти все миры некогда не пересекаются, и все продолжает трепыхаться за 24+ часа. А если ты разбираешь эти авгиевы конюшни, то как правило спасибо не говорят, но молча используют пока не найдется следующий такой разбиратель.
Нетехническая статья про технические статьи