Оглавление
- Итак, нам надо посчитать управленческую себестоимость по ФИФО, в УПП. – начал рассуждать Иван. – Исходные данные – РАУЗ, и посчитанная в нем бухгалтерская себестоимость.
- Может, проще на ERP перейти? – спросил Стас.
- Не, там вроде вообще все плохо с упр. себестоимостью.
- С чего ты взял?
- На партнерской конференции встречал обсуждение про это. – ответил Иван. – Там Сергей Бирюков, по-моему, об этом писал.
- Че за черт?
- В смысле? Возмущаешься, что в ERP нет упр.себестоимости?
- Нет, че за черт этот Бирюков?
- Сиди молчи, колхозник. – улыбнулся Иван. – Это уважаемый человек. Он, вроде, не программист, но методическую часть знает очень хорошо. Раньше по УПП много писал, сейчас – по ERP.
- Че, реально разбирается?
- Да. Ну, мне так кажется. И вроде на конференции авторитетом пользуется. Мы с ним много общались, когда я структуру затрат делал. Он ее куда-то впендюрил, в проект, и даже статью об этом написал.
- Вот жук… Тебе отчислил?
- Чего отчислил?
- Ну денег, чего.
- Нафига? – нахмурился Иван. – Блин, ты чего гонишь, Стас. Бесплатная обработка, которую тыщи человек скачали. Нафига мне с нее отчисления?
- Да так я, че ты. Нет и нет.
- Ладно, не отвлекаемся. Про ERP забыли.
- Ты про СКД что-то говорил. – уточнил Стас. – Давай рассказывай, нафига оно тут.
- Ну смотри сам. Нам надо посчитать себестоимость, не трогая регистры и документы. Так?
- Почему так? Кто сказал, что регистры нельзя трогать?
- Ты не слушал что ли, когда мы с Евгенией разговаривали? Первичку делают бухгалтеры, экономистам документы трогать нельзя. Значит, они – экономисты – не могут проводить документы. Значит, у нас не появится движений по регистрам.
Ну, то есть, если мы добавим какой-то новый регистр, в котором будем держать нашу себестоимость, то нам это ничем не поможет – движения там не появятся.
- Почему не появятся-то? – возмутился Стас. – Ты добавляешь регистр, пишешь обработки проведения для всех первичных документов, бухгалтера же все равно доки проводят – вот и будут тебе движения.
- Да, только если что-то нам, для наших целей, подходить не будет, мы не сможем ничего сделать. Понимаешь? Элементарно – документ перепровести не сможем, чтобы движения переформировались.
- А, вон ты про что… И чего делать?
- Не формировать никаких движений под первичкой. Достаточно тех данных, что есть в типовых регистрах. Их и будем использовать.
- Это как? В смысле – использовать? – искренне удивился Стас.
- Подход, вроде, не новый – такое есть и в УПП, когда правила формирования движений описываются декларативно. Помнишь, у регистров учета затрат есть макеты?
- Да, помню. Они такие страшные…
- Ну да, убого сделано. Но для типовой конфигурации – сойдет, там другого выхода нет. У них правила формирования движений должны жить в конфигурации.
- А у нас?
- А у нас они могут жить в виде схем компоновки.
- Вроде начинаю понимать… - Стас уставился в потолок и начал рассуждать. - Пишешь схему, в которой читаешь документ, его движения по нужным регистрам, и вываливаешь в нужном тебе виде. Так, стоп, а дальше что? Просто в ОЗУ вывалить таблицу?
- Нет, мы ее запишем в регистр.
- Какой регистр? Ты ж сказал, что не будем регистр делать.
- Не будем под первичку регистр делать. Сделаем отдельный документ, типа расчета себестоимости, и под него добавим регистр. Движения будет формировать наш документ, по всей первичке сразу. За месяц, разумеется.
- О, ничего себе. Щас, погоди, соображу… - задумался Стас.
- Давай, соображай. Так-то вроде круто получается. Нафига лезть в проведение документов, писать там код, если можно движения получить за один раз?
- Слушай, а разве типовой расчет себестоимости не так делает? Он же тоже кучу движений делает.
- Да, делает. Только он, как это сказать… Доделывает. Первичка пишет то, что умеет, ну или что знает на момент проведения. А расчет себестоимости доделывает. В первую очередь, конечно, суммы рассчитывает и корректирует. Но еще и распределение затрат делает. И опять суммы корректирует.
- Да, да, знаю я. Туда-сюда копейки гоняет, пока не задолбается.
- Или пока не упрется в погрешность, или в ограничение количества итераций расчета.
- Хорошо… - опять задумался Стас. – Все движения всех документов мы сформируем, и запишем в один регистр. Погоди, а как в один регистр? Там же регистратор есть. Получается все равно движения под первичкой будут?
- Нет, зачем. Регистратором всех записей будет один документ – наш. Кстати, давай ему название дадим сразу, так обсуждать удобнее будет. Может, пересчет себестоимости?
- Почему пересчет? Мы же расчет делаем? – удивился Стас.
- Ну, не совсем расчет. Мы же беззастенчиво используем чужие цифры – те, которые посчитал типовой расчет себестоимости, типовые обработки проведения и так далее.
- Не понял все равно… Какие цифры мы используем?
- Ну вот проводится у тебя поступление товаров и услуг – материалы пришли. В регистрах РАУЗ все движения, приходные, сформировались. Так?
- Так.
- А мы их берем и используем в своих расчетах. И суммы там есть.
- Так они же неправильные. Нам не подходят.
- Почему? Как раз в случае поступления – подходят, еще как. Там суммы прямо из документа, они не изменятся уже, потому что ни от чего не зависят – ни от остатков, ни от какого-либо другого контекста.
- А, да, туплю… А с расходными движениями как? Там суммы кривые.
- Не просто кривые, их там может вообще не быть, сумм-то. А нам они и не нужны. Там если и есть суммы, то они посчитаны по регл.учету, а там у нас по средней считается. Мы не будем эти суммы брать, только количества.
- А суммы откуда возьмутся?
- В этом и состоит наша задача – рассчитать суммы списаний. Это будет делать наш пересчет себестоимости. Смотри. Берем приходные документы, как есть, и пишем в наш регистр. Даты движений ставим равными датам документов, а дальше…
- Это как так? Тогда у разных записей регистра будут разные даты. Так разве можно?
- Конечно, а почему нет?
- Ну то есть у нашего документа одна дата, а в его движениях – разные даты?
- Да, а что такого?
- Да ничего… Необычно просто. В типовых так не делают.
- В типовых и ФИФО правильного нет, ни в одной конфигурации. Нам-то что с того. Ладно, дальше слушай.
Вот взяли мы все приходы, записали в регистр. Можем добавить измерение в регистр, которое будет хранить ссылку на первичный документ. Так, на всякий случай. Хотя… Нет, не измерение, а реквизит. Пусть валяется.
Дальше. Суммы берем как есть, количества тоже. И главное – приходный документ становится партией. Это уже измерение регистра. Согласен?
- Ну да. Не все понимаю пока, но ты продолжай.
- Вот спасибо. Итак, таблица приходов есть. Теперь нужны расходы. Берем все расходные документы, и точно так же пишем в регистр, только суммы не заполняем. Ну и партию, разумеется, тоже пустой оставляем.
Дальше наш алгоритм работает просто, как автомат Калашникова. У него есть расходные движения с пустой партией – это, типа, задания для расчета. Документ наш ползет по регистру, сверху вниз, и для каждого расходного движения ищет подходящую партию, и вычисляет сумму. Удаляет запись с пустой партией, добавляет запись с заполненной партией. Возможно, не одну запись добавит, а несколько – ну, это понятно.
- Нет, не понятно… Зачем несколько?
- Стас, не тупи. Если списывается 10 штук, а партий три – 1, 5 и 8 штук. Будет три движения.
- А, это как в партионном учете?
- Да. Раз мы ползем по регистру сверху вниз, и перезаписываем конкретные записи, в любой момент времени нам известны актуальные остатки – на дату той записи, которую мы рассчитываем. И все, красота.
- А перемещения?
- А что перемещения?
- Ну там не только расходная, но и приходная запись есть.
- Точно… Блин… Не, нормально! Смотри. По перемещениям есть две записи. Мы сделаем, как в РАУЗе – будем хранить корреспонденцию. Расходная запись будет знать о приходной, а приходная – о расходной. Соответственно, когда рассчитали партию для расходной записи – смело идем в приходную, лепим ту же сумму и партию. Разбиваем приходную тоже, на несколько кусков, если надо. И все!
- А отчет производства за смену?
- Да то же самое. Разница лишь в том, что там номенклатура не совпадает, и вообще аналитика. ОПзС потребляет материалы не со склада, а из НЗП. Так?
- Так.
- Ну вот. У нас материалы в НЗП будут лежать со своими партиями – требование-накладная будет обрабатываться так же, как перемещение. ОПзС списывает материалы с их партиями, и делает приход на склад, но партией уже будет сам ОПзС. Мы только суммы прокинем.
- Погоди, так это то же самое, что типовой партионный учет… Там ОПзС тоже делает приход и ставит себя партией.
- Не то же самое. У них никак нельзя узнать, из каких партий материалов составлена партия продукции. А у нас – можно будет.
- Как? Не пойму… - хмурился Стас.
- Корреспонденцией, как. Только что обсуждали. У нас приходное движение знает, из каких расходных оно сформировано. В расходных – партия материалов. В приходном – партия продукции. Все, можно запросом собрать.
- А, и структуру построить?
- Да, кстати, шаришь. Старая моя структура затрат ничего не знала про партии, а тут можно суперчетко сделать. Не гадать, что из чего сделано, а прям по регистру тюк-тюк-тюк, пробежаться, и собрать. Так, вроде, в ERP делают – по партиям бегают.
- Так, ладно. Не могу вспомнить, а где тут СКД? Мы с него вроде начали.
- Мы сделаем справочник, типа источники данных себестоимости. Внутри каждого элемента – схема компоновки. Каждая конкретная схема описывает алгоритм формирования движений для каждого типа документа. Где-то можно несколько документов одной схемой описать, где-то – наоборот, двумя схемами один документ. Не важно. Схема выполняется, дает нам большую таблицу – например, все движения всех поступлений. Мы тупо пишем их в регистр. Никакого проведения, никакой последовательности – бац, и записали.
- Прикольно… Необычно, правда.
- Да ты дальше думай. Мы же схемы компоновки пишем в пользовательском режиме, так?
- Так.
- А значит, можем настраивать, например, отборы по данным. В конфигураторе-то данных нет, только метаданные и предопределенные элементы.
- Ну, и зачем это?
- Как зачем? Во-первых, мы можем делать разное поведение, формировать разные движения по документу какого-то типа, в зависимости от данных.
Например, можем схлопывать номенклатуру. Возьмем какую-нибудь группу, там с болтиками дешевыми, я не знаю, и схлопнем – будет одна номенклатура «Болтики». И все, вместо тысячи записей будет одна.
Во-вторых, мы можем использовать не только данные документа. Например, ставит бухгалтерия какую-то статью затрат в получении услуг. А нам, то есть экономистам, эта статья не нравится. Или они хотят разбивать ее на две части. А бухгалтерия – не хочет, им же «лишь бы закрылось». Но нам-то пофиг, у нас СКД – как напишешь в запросе, так и будет. Хочешь – статью заменяй, хочешь – на три разбивай, хочешь – схлопывай, и т.д.
В-третьих, некоторые документы мы можем вообще игнорировать.
- Это как так? – удивился Стас.
- Элементарно. Вот бухгалтерия, например, делает тупые перемещения – одна и та же номенклатура, один и тот же склад, но разные счета учета – перекидывают, например, с 10.01 на 10.02. В управленческом учете такая фигня не нужна, а типовая конфа все равно сделает и приход, и расход, а потому будет мучиться с расчетом. Мы же такие документы вообще проигнорируем.
- Слушай, клево! Блин, мне нравится!
- Еще б тебе не нравилось. Но ты дальше слушай.
В-четвертых – и это, на мой взгляд, самое главное – мы можем менять правила расчета на лету. Написали схему, посчитали, чего-то получилось. Смотрим – ага, криво. Меняем схему компоновки, тут же пересчитываем, получаем результат. Понимаешь? Без программирования, без обновления конфигурации БД, без перепроведения документов. Легко и быстро.
- Да-да, круто! Это ж так играться можно, до бесконечности!
- Мало того, что играться. Если подумать дальше, мы можем вообще неэпическую систему сделать – сценарный расчет себестоимости.
Смотри. Написали мы этих схем – допустим, двадцать. В документе нашем, который пересчет себестоимости, все их перечислили. Он честно посчитал.
Потом мы делаем другие схемы компоновки – еще двадцать. Создаем другой документ пересчета, за тот же месяц, указываем новые схемы – по сути, новые правила расчета. Проводим, и вуаля – у нас две себестоимости, посчитанные по разным правилам. Независимые друг от друга, но каждая – самодостаточная.
Наверное, лучше новый справочник завести, типа настройки пересчета, или сценарий расчета, который будет хранить набор схем. И все, можно считать, хоть пять разных себестоимостей.
- А нафига? Им вроде одна нужна.
- Ну, прям щас я не знаю, нафига. Но ты же сам видишь, такая возможность прям сама напрашивается. И делать почти ничего не надо – добавить справочник сценариев, и засунуть его в регистр в качестве измерения. Ну, чтобы одну модель расчета от другой отделить.
- А, ну ладно тогда. Пусть будет.
- Хорошо. Что думаешь, круто получилось?
- Так не получилось же еще ничего, фантазируем просто.
- Я думаю, получится. Сам буду делать. Слишком интересная задача, чтобы кому-то отдавать.
Внезапно дверь в кабинет программистов распахнулась, и в нее буквально влетела офис-менеджер Ксения.
- Иван, срочно к директору
