Быстрее. Глава 3

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

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

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

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

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

— Че за черт?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— А у нас?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Так.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Так.

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

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

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

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

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

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

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

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

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

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

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

— Так.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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