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

15.10.18

Сообщество - О жизни

Третья глава знаменитой книги про 1Сников

Оглавление

 

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

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

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

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

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

 - Че за черт?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 - А у нас?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 - Так.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 - Так.

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

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

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

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

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

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

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

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

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

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

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

 - Так.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

Жизнь программиста 1С на Линукс, это возможно?

О жизни Linux Системный администратор Программист Платформа 1С v8.3 Россия Бесплатно (free)

Использование Linux в качестве основной ОС для программиста 1С, возможно ли это? Решил поделиться личным опытом работы перехода на эту систему. В статье моя история без технических деталей максимально простым языком. И, спойлер, да, жизнь на Линуксе для разработчика 1С возможна и с каждым годом становится всё комфортней. Статья рассчитана на людей, с Линуксом не знакомых, специалистов прошу не кидаться помидорами.

16.05.2024    3550    soulner    32    

38

"250+ тысяч, в штат и работу пока не ищу": как изменился типичный 1С-ник в 2023 году

О жизни Россия Бесплатно (free)

Подводим итоги работы в 1С за 2023 год. Все о вас: 4 подробных раздела с цифрами, графиками и ужасными цветами диаграмм (должна же где-то быть стабильность).

08.02.2024    24066    Neti    85    

116

Адекватность работодателя. Как её определить? Часть 2. Процесс работы, от испытательного срока до увольнения

О жизни Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного работодателя. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все недостатки работодателей от момента собеседования до момента увольнения. Все этапы, как всегда, подкреплены реальными случаями из моего опыта.

22.01.2024    4283    biimmap    67    

72

Адекватность работодателя. Как её определить? Часть 1. Собеседование, заключение трудового договора

О жизни Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного работодателя. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все недостатки работодателей от момента собеседования до момента увольнения. Все этапы, как всегда, подкреплены реальными случаями из моего опыта.

16.01.2024    5712    biimmap    99    

79

Идеальное место работы для ЗУПера... Какое оно?! Часть 1. Негативные тенденции, ненужные знания.

О жизни Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Бесплатно (free)

Импортозамещение увеличило потребность в архитекторах, аналитиках, разработчиках 1С, в т.ч. по ЗУП. Все их ищут всеми возможными способами, но не могут найти и не знают, чем же их завлечь к себе!? Давайте разберёмся в этом вопросе!

27.11.2023    4699    biimmap    52    

73

15 лет вместе...

О жизни Сообщество Бесплатно (free)

Прочитав название публикации, мысль возникает о свадьбе... Но речь не об этом!

25.08.2023    2703    biimmap    24    

51

Как изменилось собеседование разработчиков 1С за последний год

О жизни Россия Бесплатно (free)

«Многие кандидаты хотят от собеседования простую вещь: чтобы оно длилось пять минут и брали сразу на 300 000 в наносекунду», — Эльдар Мингалиев, разрабатывает новые форматы собеседований.

22.08.2023    14411    Neti    161    

108
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. katenok86 246 24.08.18 14:05 Сейчас в теме
Вот не понимаю я смысла использовать реальные номера и фамилии особенно в таком контексте.
2. Dem1urg 389 26.08.18 18:35 Сейчас в теме
(1) А почему вы думаете, что они реальные?
3. katenok86 246 27.08.18 08:49 Сейчас в теме
(2)Я знаю, партнерский форум же читаю
13. 1c-intelligence 12808 28.08.18 08:12 Сейчас в теме
(1) убрал реального персонажа.
18. 1c-intelligence 12808 03.09.18 10:42 Сейчас в теме
(13) вернул реального персонажа, т.к. Сергей Бирюков согласился стать персонажем книги.
Capitullo; +1 Ответить
4. ilialin 27.08.18 10:34 Сейчас в теме
- Иван, срочно к директору

Чувствую, уволят его
NatalkaBal; +1 Ответить
5. dock 44 27.08.18 14:00 Сейчас в теме
Где ссылки на первую и вторую часть ???
Ну вот что стоит сделать "оглавление" в начале статьи с нужными ссылками...
В идеале, с выходом новой части - пройтись по всем старым и обновить "оглавление"...
6. 1c-intelligence 12808 27.08.18 14:31 Сейчас в теме
(5) добавил оглавление во все три главы.
7. YaroslavHolovatiy 27.08.18 15:09 Сейчас в теме
(6) Здравствуйте, в оглавлении, ссылка на 3-ю часть открывает 2-ю. Поправьте пожалуйста.
12. 1c-intelligence 12808 28.08.18 06:46 Сейчас в теме
8. JohnGalt 58 27.08.18 15:46 Сейчас в теме
Идея неплохая по схемам расчета себестоимости. Разные даты записей из одного документа тоже хорошо, поскольку РСВ стоимость неправильно рассчитывает, если много расходных на одну дату. И связь прихода с расходом нужна. Особенно для упр. отчетности, чтобы например связать статьи затрат в учете готовой продукции с номенклатурой-материалом.

Для устранения расхождений можно также контроль уникальности времени списания добавить для документов расхода. И/Или объединять все расходные за день в несколько больших по группам (склад, характеристика, серия, качество и т.д)

Но что делать если в ERP требуется как раз указывать разную стоимость товара и ОС для УУ и БУ? Без добавления реквизитов не обойтись.
9. alex-l19041 8 27.08.18 17:40 Сейчас в теме
В типовых и ФИФО правильного нет, ни в одной конфигурации
- чем можете обосновать?
10. 1c-intelligence 12808 27.08.18 17:48 Сейчас в теме
(9) это кому вопрос? Если героям книги, то они не ответят. Если мне, то я с героями не согласен.
UniversaLL; dock; Dem1urg; +3 Ответить
11. dock 44 27.08.18 22:47 Сейчас в теме
(10)
Мнения автора могут не совпадать с его точкой зрения. — «Памяти среднего класса» (предисловие) Generation «П»
14. brr 183 28.08.18 14:41 Сейчас в теме
15. shutilin 30.08.18 17:44 Сейчас в теме
Вот удобный случай вопрос по теме задать, задача та же, только УНФ )))
Скажите, Иван, партионный учет в УНФ, он как-бы есть, но...
1. Перед проведением подбирать и заполнять партии в табличной части документа, при отмене проведения очищать? Как-то диковато кажется.
2. Подбирать и подставлять партии после проведения прямо в движения документа?
3. Не трогать родной механизм всё сделать на своих объектах, регламентами при закрытии периода? Как в книге?
16. 1c-intelligence 12808 30.08.18 17:52 Сейчас в теме
(15) я УНФ, увы, не знаю. Но первые 2 варианта лично мне не нравятся. Я за третий.
17. shutilin 30.08.18 18:22 Сейчас в теме
(16) Большое спасибо за ответ!
А УНФ - чудо, быстро, красиво, легко адаптируется ко всему. Используем для сложного, многопередельного машиностроительного производства.
Партионный учет там есть, там все есть, но все в минимальном варианте, все надо доделывать. В оригинале партии там нужно вручную выбирать в документах.
Оставьте свое сообщение