Потом доделаем. Глава 3, в которой, вроде бы, придумано решение Интересной Задачи

Оглавление

 

— Итак, нам надо посчитать управленческую себестоимость по ФИФО, в УПП. – начал рассуждать Иван. – Исходные данные – РАУЗ, и посчитанная в нем бухгалтерская себестоимость.

 — Может, проще на ERP перейти? – спросил Стас.

 — Не, там вроде вообще все плохо с упр. себестоимостью.

 — С чего ты взял?

 — На партнерской конференции встречал обсуждение про это. – ответил Иван. – Там Сергей Бирюков, по-моему, об этом писал.

 — Че за черт?

 — В смысле? Возмущаешься, что в ERP нет упр.себестоимости?

 — Нет, че за черт этот Бирюков?

 — Сиди молчи, колхозник. – улыбнулся Иван. – Это уважаемый человек. Он, вроде, не программист, но методическую часть знает очень хорошо. Раньше по УПП много писал, сейчас – по ERP.

 — Че, реально разбирается?

 — Да. Ну, мне так кажется. И вроде на конференции авторитетом пользуется. Мы с ним много общались, когда я структуру затрат делал. Он ее куда-то впендюрил, в проект, и даже статью об этом написал.

 — Вот жук… Тебе отчислил?

 — Чего отчислил?

 — Ну денег, чего.

 — Нафига? – нахмурился Иван. – Блин, ты чего гонишь, Стас. Бесплатная обработка, которую тыщи человек скачали. Нафига мне с нее отчисления?

 — Да так я, че ты. Нет и нет.

 — Ладно, не отвлекаемся. Про ERP забыли.

 — Ты про СКД что-то говорил. – уточнил Стас. – Давай рассказывай, нафига оно тут.

 — Ну смотри сам. Нам надо посчитать себестоимость, не трогая регистры и документы. Так?

 — Почему так? Кто сказал, что регистры нельзя трогать?

 — Ты не слушал что ли, когда мы с Евгенией разговаривали? Первичку делают бухгалтеры, экономистам документы трогать нельзя. Значит, они – экономисты – не могут проводить документы. Значит, у нас не появится движений по регистрам.

Ну, то есть, если мы добавим какой-то новый регистр, в котором будем держать нашу себестоимость,  то нам это ничем не поможет – движения там не появятся.

 — Почему не появятся-то? – возмутился Стас. – Ты добавляешь регистр, пишешь обработки проведения для всех первичных документов, бухгалтера же все равно доки проводят – вот и будут тебе движения.

 — Да, только если что-то нам, для наших целей, подходить не будет, мы не сможем ничего сделать. Понимаешь? Элементарно – документ перепровести не сможем, чтобы движения переформировались.

 — А, вон ты про что… И чего делать?

 — Не формировать никаких движений под первичкой. Достаточно тех данных, что есть в типовых регистрах. Их и будем использовать.

 — Это как? В смысле – использовать? – искренне удивился Стас.

 — Подход, вроде, не новый – такое есть и в УПП, когда правила формирования движений описываются декларативно. Помнишь, у регистров учета затрат есть макеты?

 — Да, помню. Они такие страшные…

 — Ну да, убого сделано. Но для типовой конфигурации – сойдет, там другого выхода нет. У них правила формирования движений должны жить в конфигурации.

 — А у нас?

 — А у нас они могут жить в виде схем компоновки.

 — Вроде начинаю понимать… — Стас уставился в потолок и начал рассуждать. — Пишешь схему, в которой читаешь документ, его движения по нужным регистрам, и вываливаешь в нужном тебе виде. Так, стоп, а дальше что? Просто в ОЗУ вывалить таблицу?

 — Нет, мы ее запишем в регистр.

 — Какой регистр? Ты ж сказал, что не будем регистр делать.

 — Не будем под первичку регистр делать. Сделаем отдельный документ, типа расчета себестоимости, и под него добавим регистр. Движения будет формировать наш документ, по всей первичке сразу. За месяц, разумеется.

 — О, ничего себе. Щас, погоди, соображу… — задумался Стас.

 — Давай, соображай. Так-то вроде круто получается. Нафига лезть в проведение документов, писать там код, если можно движения получить за один раз?

 — Слушай, а разве типовой расчет себестоимости не так делает? Он же тоже кучу движений делает.

 — Да, делает. Только он, как это сказать… Доделывает. Первичка пишет то, что умеет, ну или что знает на момент проведения. А расчет себестоимости доделывает. В первую очередь, конечно, суммы рассчитывает и корректирует. Но еще и распределение затрат делает. И опять суммы корректирует.

 — Да, да, знаю я. Туда-сюда копейки гоняет, пока не задолбается.

 — Или пока не упрется в погрешность, или в ограничение количества итераций расчета.

 — Хорошо… — опять задумался Стас. – Все движения всех документов мы сформируем, и запишем в один регистр. Погоди, а как в один регистр? Там же регистратор есть. Получается все равно движения под первичкой будут?

 — Нет, зачем. Регистратором всех записей будет один документ – наш. Кстати, давай ему название дадим сразу, так обсуждать удобнее будет. Может, пересчет себестоимости?

 — Почему пересчет? Мы же расчет делаем? – удивился Стас.

 — Ну, не совсем расчет. Мы же беззастенчиво используем чужие цифры – те, которые посчитал типовой расчет себестоимости, типовые обработки проведения и так далее.

 — Не понял все равно… Какие цифры мы используем?

 — Ну вот проводится у тебя поступление товаров и услуг – материалы пришли. В регистрах РАУЗ все движения, приходные, сформировались. Так?

 — Так.

 — А мы их берем и используем в своих расчетах. И суммы там есть.

 — Так они же неправильные. Нам не подходят.

 — Почему? Как раз в случае поступления – подходят, еще как. Там суммы прямо из документа, они не изменятся уже, потому что ни от чего не зависят – ни от остатков, ни от какого-либо другого контекста.

 — А, да, туплю… А с расходными движениями как? Там суммы кривые.

 — Не просто кривые, их там может вообще не быть, сумм-то. А нам они и не нужны. Там если и есть суммы, то они посчитаны по регл.учету, а там у нас по средней считается. Мы не будем эти суммы брать, только количества.

 — А суммы откуда возьмутся?

 — В этом и состоит наша задача – рассчитать суммы списаний. Это будет делать наш пересчет себестоимости. Смотри. Берем приходные документы, как есть, и пишем в наш регистр. Даты движений ставим равными датам документов, а дальше…

 — Это как так? Тогда у разных записей регистра будут разные даты. Так разве можно?

 — Конечно, а почему нет?

 — Ну то есть у нашего документа одна дата, а в его движениях – разные даты?

 — Да, а что такого?

 — Да ничего… Необычно просто. В типовых так не делают.

 — В типовых и ФИФО правильного нет, ни в одной конфигурации. Нам-то что с того. Ладно, дальше слушай.

Вот взяли мы все приходы, записали в регистр. Можем добавить измерение в регистр, которое будет хранить ссылку на первичный документ. Так, на всякий случай. Хотя… Нет, не измерение, а реквизит. Пусть валяется.

Дальше. Суммы берем как есть, количества тоже. И главное – приходный документ становится партией. Это уже измерение регистра. Согласен?

 — Ну да. Не все понимаю пока, но ты продолжай.

 — Вот спасибо. Итак, таблица приходов есть. Теперь нужны расходы. Берем все расходные документы, и точно так же пишем в регистр, только суммы не заполняем. Ну и партию, разумеется, тоже пустой оставляем.

Дальше наш алгоритм работает просто, как автомат Калашникова. У него есть расходные движения с пустой партией – это, типа, задания для расчета. Документ наш ползет по регистру, сверху вниз, и для каждого расходного движения ищет подходящую партию, и вычисляет сумму. Удаляет запись с пустой партией, добавляет запись с заполненной партией. Возможно, не одну запись добавит, а несколько – ну, это понятно.

 — Нет, не понятно… Зачем несколько?

 — Стас, не тупи. Если списывается 10 штук, а партий три – 1, 5 и 8 штук. Будет три движения.

 — А, это как в партионном учете?

 — Да. Раз мы ползем по регистру сверху вниз, и перезаписываем конкретные записи, в любой момент времени нам известны актуальные остатки – на дату той записи, которую мы рассчитываем. И все, красота.

 — А перемещения?

 — А что перемещения?

 — Ну там не только расходная, но и приходная запись есть.

 — Точно… Блин… Не, нормально! Смотри. По перемещениям есть две записи. Мы сделаем, как в РАУЗе – будем хранить корреспонденцию. Расходная запись будет знать о приходной, а приходная – о расходной. Соответственно, когда рассчитали партию для расходной записи – смело идем в приходную, лепим ту же сумму и партию. Разбиваем приходную тоже, на несколько кусков, если надо. И все!

 — А отчет производства за смену?

 — Да то же самое. Разница лишь в том, что там номенклатура не совпадает, и вообще аналитика. ОПзС потребляет материалы не со склада, а из НЗП. Так?

 — Так.

 — Ну вот. У нас материалы в НЗП будут лежать со своими партиями – требование-накладная будет обрабатываться так же, как перемещение. ОПзС списывает материалы с их партиями, и делает приход на склад, но партией уже будет сам ОПзС. Мы только суммы прокинем.

 — Погоди, так это то же самое, что типовой партионный учет… Там ОПзС тоже делает приход и ставит себя партией.

 — Не то же самое. У них никак нельзя узнать, из каких партий материалов составлена партия продукции. А у нас – можно будет.

 — Как? Не пойму… — хмурился Стас.

 — Корреспонденцией, как. Только что обсуждали. У нас приходное движение знает, из каких расходных оно сформировано. В расходных – партия материалов. В приходном – партия продукции. Все, можно запросом собрать.

 — А, и структуру построить?

 — Да, кстати, шаришь. Старая моя структура затрат ничего не знала про партии, а тут можно суперчетко сделать. Не гадать, что из чего сделано, а прям по регистру тюк-тюк-тюк, пробежаться, и собрать. Так, вроде, в ERP делают – по партиям бегают.

 — Так, ладно. Не могу вспомнить, а где тут СКД? Мы с него вроде начали.

 — Мы сделаем справочник, типа источники данных себестоимости. Внутри каждого элемента – схема компоновки. Каждая конкретная схема описывает алгоритм формирования движений для каждого типа документа. Где-то можно несколько документов одной схемой описать, где-то – наоборот, двумя схемами один документ. Не важно. Схема выполняется, дает нам большую таблицу – например, все движения всех поступлений. Мы тупо пишем их в регистр. Никакого проведения, никакой последовательности – бац, и записали.

 — Прикольно… Необычно, правда.

 — Да ты дальше думай. Мы же схемы компоновки пишем в пользовательском режиме, так?

 — Так.

 — А значит, можем настраивать, например, отборы по данным. В конфигураторе-то данных нет, только метаданные и предопределенные элементы.

 — Ну, и зачем это?

 — Как зачем? Во-первых, мы можем делать разное поведение, формировать разные движения по документу какого-то типа, в зависимости от данных.

Например, можем схлопывать номенклатуру. Возьмем какую-нибудь группу, там с болтиками дешевыми, я не знаю, и схлопнем – будет одна номенклатура «Болтики». И все, вместо тысячи записей будет одна.

Во-вторых, мы можем использовать не только данные документа. Например, ставит бухгалтерия какую-то статью затрат в получении услуг. А нам, то есть экономистам, эта статья не нравится. Или они хотят разбивать ее на две части. А бухгалтерия – не хочет, им же «лишь бы закрылось». Но нам-то пофиг, у нас СКД – как напишешь в запросе, так и будет. Хочешь – статью заменяй, хочешь – на три разбивай, хочешь – схлопывай, и т.д.

В-третьих, некоторые документы мы можем вообще игнорировать.

 — Это как так? – удивился Стас.

 — Элементарно. Вот бухгалтерия, например, делает тупые перемещения – одна и та же номенклатура, один и тот же склад, но разные счета учета – перекидывают, например, с 10.01 на 10.02. В управленческом учете такая фигня не нужна, а типовая конфа все равно сделает и приход, и расход, а потому будет мучиться с расчетом. Мы же такие документы вообще проигнорируем.

 — Слушай, клево! Блин, мне нравится!

 — Еще б тебе не нравилось. Но ты дальше слушай.

В-четвертых – и это, на мой взгляд, самое главное – мы можем менять правила расчета на лету. Написали схему, посчитали, чего-то получилось. Смотрим – ага, криво. Меняем схему компоновки, тут же пересчитываем, получаем результат. Понимаешь? Без программирования, без обновления конфигурации БД, без перепроведения документов. Легко и быстро.

 — Да-да, круто! Это ж так играться можно, до бесконечности!

 — Мало того, что играться. Если подумать дальше, мы можем вообще неэпическую систему сделать – сценарный расчет себестоимости.

Смотри. Написали мы этих схем – допустим, двадцать. В документе нашем, который пересчет себестоимости, все их перечислили. Он честно посчитал.

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

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

 — А нафига? Им вроде одна нужна.

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

 — А, ну ладно тогда. Пусть будет.

 — Хорошо. Что думаешь, круто получилось?

 — Так не получилось же еще ничего, фантазируем просто.

 — Я думаю, получится. Сам буду делать. Слишком интересная задача, чтобы кому-то отдавать.

Внезапно дверь в кабинет программистов распахнулась, и в нее буквально влетела офис-менеджер Ксения.

 — Иван, срочно к директору