1с как распределить сумму пропорционально
Тема полезная, если не просто делать, что скажет главбух, а еще и подумать..
Хоть это и не совсем логично, на первый взгляд :) Или наоборот – очень даже логично…
А чтобы понять логику – отвлечемся на секунду на “теорию”, чтобы было ясно, зачем это все..
Есть стандартный способ классификации затрат:
- прямые затраты – все, что можно точно (знаем сколько) отнести на себестоимость выпуска конкретной продукции. Например, шпон используется только для одной позиции монтажных плит – все, это прямая затрата.
- косвенные затраты – все остальные. Знаем только, объем затраты за месяц и что потратили на выпуск нескольких видов продукции – а сколько на каждую не считали.
Что важно – чем более точно мы соотносим затраты с продукцией (чем выше доля прямых затрат), тем точнее будет оценка ее себестоимости.
И наоборот – чем больше косвенных, тем больше “совы на глобус”, потому что косвенные затраты вносят произвол. Отсюда все модели экономического анализа по маржинальной прибыли / прямым предельным затратам, CVP-анализ и прочие полезные в быту вещи.
Если эта тема интересна – рекомендуем погрузиться, например, в немецкий контроллинг, наглядно и четко, как железный орднунг. Только не путать с тем, что понимает под контроллингом 1С :).
Итак, вроде понятно, что если какие-то косвенные затраты можно отнести на конкретную продукцию – это хорошо.
А как с этим в 1С?
Логика так же – расходы, отражаемые по статьям затрат (так называемые постатейные расходы), по своей сути является косвенными. То есть они распределяются на себестоимость продукции пропорционально некоторому значению, например, по количеству выпущенной продукции. К примеру, подрядчик отремонтировал наш станок, сумму расходов по ремонту мы можем списать на выпуски продукции соответствующего цеха пропорционально плановой себестоимости.
Однако есть механизмы, которые позволяют квалифицировать постатейные расходы как прямые, то есть соотнести их с конкретной партией выпуска, продукцией или заказом на производство.
В этом видео мы рассмотрим такие механизмы, а также посмотрим, что нового появилось в 2.5.7 для решения задач, подобных этой:
При выполнении ТО в цехе №3 потребовались услуги подрядчика по настройке станка ЧПУ, стоимость 50 000 руб.
Нужно отразить эти затраты в себестоимости ТО, выполненного по конкретному цеху, чтобы учесть в себестоимости продукции именно этого цеха.
Тайминг ключевых моментов видео:
- 00:30 – общая теория постатейных расходов
- 01:15 – постановка задачи
- 02:30 – описание варианта решения задачи на версии 1C:ERP младше 2.5.7 через обособление выпускаемой работы
- 03:25 – альтернативный вариант решения задачи – использование правил распределения расходов на версии 1C:ERP младше 2.5.7
- 04:30 – отражение выпуска ремонтных работ через оформление документа Производство без заказа
- 06:25 – отражение услуг подрядчика и соотношение их с партией выпуска ремонтных работ
- 08:25 – выполнение закрытия месяца
- 08:50 – работа с рабочим местом «Распределение расходов»
- 10:15 – анализ себестоимости выпущенной продукции
- 11:30 – описание альтернативного варианта решения в 1C:ERP 2.5.7 и старше
- 12:28 – закупка работ по техобслуживанию, создание документа Приобретение услуг и прочих активов
- 12:40 – создание новой статьи расходов, по которой будет отражаться поступление затрат
- 14:45 – выполнение закрытия месяца
- 14:55 – анализ результатов при помощи отчетов Движения ТМЦ и затрат в производстве по организациям и Доходы и расходы предприятия
- 15:55 – исправление ошибки с направлением деятельности
- 16:30 – финальный анализ результатов.
Приятного просмотра, да пребудет с Вами все хорошее :)
Как изучить 1С:ERP или подготовиться к Аттестации 1С:Специалист по производству ПРОЩЕ - и, самое главное, БЫСТРЕЕ?
Чтобы Вы могли быстро и без ошибок решить задачи аттестации и применить эти знания в реальных проектах, мы выпустили новый курс по подготовке к Аттестации по производству в 1С:ERP на актуальной редакции 2.5.
Периодически в работе сталкиваюсь с задачей пропорционального распределения сумм в запросе. Ситуация усложняется, когда распределяемые суммы изначально не известны и определяются в процессе выполнения запроса. Эта статья один из примеров решения такой задачи.
Основная проблема с которой сталкивается разработчик это остатки от распределения. Остатки возникают из-за округлений и представляют собой разницу между распределяемой и распределенной суммами.
Существуют разные методы решения проблемы. Один из методов - перенос разницы на элемент с самым большим значением. Недостатком такого метода является существенное изменение корректируемого элемента, при некоторых условиях. Например большое количество элементов распределения и маленькая точность округления. Иногда такой способ может привести к аномалиям, вплоть до перехода изначально положительных элементов базы распределения в отрицательные значения.
Другим методом решения проблемы является выравнивание результата не по общему итогу, а в процессе распределения по промежуточным итогам. При этом методе погрешность округлений переносится на элементы малыми частями. Следует заметить, что такой метод в сравнении с первым:
- более затратен по вычислительным ресурсам
- в результате распределения может случиться, что на элементы с одинаковыми значениями были распределены разные суммы
Вторая проблема разработчика, это определение распределяемой суммы/сумм в процессе выполнения запроса, отсутствие возможности передать распределяемую сумму/суммы в запрос параметром.
Ниже пример пропорционального распределения в запросе 1С методом выравнивания с определением распределяемых сумм в запросе.
В приложенном файле отчет с приведенным примером распределения. Проверено на релизе 8.3.10.2753.
Специальные предложения
Хотелось бы пояснений к логике запросов. Вот например какая логика в этом фрагменте, что есть ЗначениеНакопленное?
(2) Валерий, обратите внимание на соединение Элементы1.Элемент > Элементы2.Элемент. Немного не обычно, но результат как будто делается соединение по номерам строк таблицы. Соответственно каждая строка будет иметь итог предыдущих строк.
Это так должно быть, что суммы распределения отличаются в приведенном запросе от того что на картинке к статье?
https://www.forum.mista.ru/topic.php?id=616801 - распределение с "размазыванием" округления
пост 91 от Speshuric
К сожалению данный алгоритм не работает корректно при произвольных (взятых из практической задачи) значениях базы распределения.
Например, на такой таблице данных он не работает:
Временная таблица: ВТ_УправленческиеРасходы_Распределяемые (Записей в результате: 2)
УправленческиеРасходы_Распределяемые ОперационныйСегмент
27 504 652,9 Сегмент1
3 781 595,5 Прочие
Временная таблица: Данные (Записей в результате: 12)
Объект ОперационныйСегмент База
МК-00001853Экспорт Сегмент1 3 044 491,7155362
МК-00001854Внутренний рынок Сегмент1 3 149 669,367952
МК-00001854Экспорт Сегмент1 14 775 706,07857
МК-00001855Внутренний рынок Сегмент1 3 163 001,7726148
МК-00001855СНГ Сегмент1 968 615,0756743
МК-00001856Экспорт Сегмент1 1 189 318,7971243
МК-00001857Экспорт Сегмент1 1 160 673,1357024
МК-00001860Экспорт Прочие 779 552,4115997
МК-00001861Экспорт Прочие 2 041 707,0284046
МК-00001870Внутренний рынок Прочие 765 162,6133091
МК-00001871Внутренний рынок Сегмент1 53 176,9540751
МК-000013Внутренний рынок Прочие 195 173,4463082
Временная таблица: Итог (Записей в результате: 2)
СуммаБазы ОперационныйСегмент
27 504 652,8972491 Сегмент1
3 781 595,4996216 Прочие
Временная таблица: ДанныеСНакоплением (Записей в результате: 12)
Объект ОперационныйСегмент База БазаНакопленная
МК-000013Внутренний рынок Прочие 195 173,45
МК-00001853Экспорт Сегмент1 3 044 491,72
МК-00001854Внутренний рынок Сегмент1 3 149 669,37 3 044 491,72
МК-00001854Экспорт Сегмент1 14 775 706,08 6 194 161,08
МК-00001855Внутренний рынок Сегмент1 3 163 001,77 20 969 867,16
МК-00001855СНГ Сегмент1 968 615,08 24 132 868,93
МК-00001856Экспорт Сегмент1 1 189 318,8 25 101 484,01
МК-00001857Экспорт Сегмент1 1 160 673,14 26 290 802,81
МК-00001860Экспорт Прочие 779 552,41 195 173,45
МК-00001861Экспорт Прочие 2 041 707,03 974 725,86
МК-00001870Внутренний рынок Прочие 765 162,61 3 016 432,89
МК-00001871Внутренний рынок Сегмент1 53 176,95 27 451 475,94
Временная таблица: ВТ_РаспределеноПоБазе (Записей в результате: 12)
Объект База ОперационныйСегмент РаспределеноПоБазе
МК-000013Внутренний рынок 195 173,45 Прочие 195 173,45
МК-00001853Экспорт 3 044 491,72 Сегмент1 3 044 491,72
МК-00001854Внутренний рынок 3 149 669,37 Сегмент1 3 149 669,37
МК-00001854Экспорт 14 775 706,08 Сегмент1 14 775 706,08
МК-00001855Внутренний рынок 3 163 001,77 Сегмент1 3 163 001,77
МК-00001855СНГ 968 615,08 Сегмент1 968 615,08
МК-00001856Экспорт 1 189 318,8 Сегмент1 1 189 318,8
МК-00001857Экспорт 1 160 673,14 Сегмент1 1 160 673,14
МК-00001860Экспорт 779 552,41 Прочие 779 552,41
МК-00001861Экспорт 2 041 707,03 Прочие 2 041 707,03
МК-00001870Внутренний рынок 765 162,61 Прочие 765 162,61
МК-00001871Внутренний рынок 53 176,95 Сегмент1 53 176,95
Решение задачи распределения суммы пропорционально каким-либо значениям (например, оплату по договорам) с помощью одного запроса таким образом, чтобы при округлении не получалось суммарного отклонения.
В практике программирования часто встречается задача распределить сумму по элементам пропорционально значениям. Например, распределить поступившую оплату по статьям или по договорам пропорционально долгу. Если использовать простую формулу пропорции, то на округлениях может образоваться ошибка в ту или иную сторону. Обычно это решается подсчетом размера ошибки и добавлением остатка на одну из статей распределения с помощью цикла. Между тем, это можно выполнить в запросе полностью.
Итак, предположим, у нас есть таблица Долги с полями Договор и Долг. Кроме того у нас есть параметр СуммаОплаты.
Первым действием нам необходимо в поле РаспределеннаяОплата распределить сумму оплаты по договорам в соответствии с коэффициентом Долг/СуммаДолга с округлением до 2 знака после запятой (сумма долга подсчитывается с помощью вложенного запроса). В этом же запросе в поле Порядок одновременно пронумеруем договоры в порядке убывания суммы. Это нам необходимо для распределения образовавшегося "излишка". Нумерация выполняется путем самосоединения таблицы с условием на долг по договору, а также на код договора, на случай если долг окажется одинаковым.
Мы получим таблицу:
Вторым действием вычислим разницу между суммой оплаты и суммой распределения. Получив несколько копеек отклонения в ту или иную сторону, добавим по одной копейке на каждый договор. Для этого сравним сумму отклонения, умноженной на 100 и поле Порядок. Распределение выполнится таким образом, что начиная с самого большого долга, будет добавлено ровно столько копеек, на сколько было отклонение. Количество копеек отклонения заведомо не может быть больше количества договоров. В запрос для наглядности добавлены поля по всем этапам вычисления.
В результате получим таблицу:
Все, оплата распределена.
Если убрать из запроса лишние поля, то итоговый результат будет выглядеть следующим образом:
Идея, думаю, понятна. Таким же образом можно перераспределить положительные и отрицательные суммы между договорами и так далее. Как ни странно, в Интернете я похожего решения не нашел, везде пишут "запросом невозможно, делайте в цикле". Поэтому описал максимально подробно смысл каждого действия. Пользуйтесь на здоровье.
Специальные предложения
Как ни странно, в Интернете я похожего решения не нашел, везде пишут "запросом невозможно, делайте в цикле".
Gadzhalik; Никс; dhurricane; Балабас; Simonov_NPM; pavlov_dv; user1035175; BigB; acanta; Kinestetik; Franchiser; Somebody1; pm74; mifka186; vinni_pooh; Жолтокнижниг; VVi3ard; lx@; slavap; PythonJ; Alien_job; + 21 – Ответить
(1) kvikster,
Как понять "Распределить на три одинаковых документа"? Если документы (или договоры) с одинаковой суммой, но разными кодами, то излишек распределится в порядке очередности кода на сколько хватит. А если это одинаковые документы, то в чем тогда смысл распределения? Исходная таблица по определению не должна содержать одинаковые значения документа. Если они одинаковые, то их нужно сгруппировать до распределения. В конечном итоге предполагается получить движения, где документ - измерение, а распределенная сумма - ресурс. Какой смысл в движениях с разными ресурсами, но одинаковыми измерениями?
Поясните или приведите пример задачи, если я неправильно понял.
Для полноты картины не хватает ссылки на основательную статью по этой теме : "Честное распределение суммы по таблице значений" . Безотносительно техники решения в указанной статье сравниваются разные принципы отнесения ошибок округления на конкретные строки базы распределения. Из статьи, кажется, следует, что упорядочивание по величине долга - не лучший метод. Мне кажется, что лучше упорядочивать по величине ошибки округления. Тогда будет работать критерий минимакса ошибки представления.
Похожая задача вроде бы возникает при масштабировании областей в растровой графике. Когда требуется увеличить площадь под линией на заданную величину, сохранив ее форму. Используемый здесь метод будет всегда поправлять верхнюю часть ограничительной линии, внося заметные на взгляд искажения.
Но по сравнению с отнесением всей невязки на одну строку (что приводит к еще более простому запросу) этот запрос получше.
(3) ildarovich, Отличная статья. По хорошему, нужно не ссылку сюда добавлять, а вообще статью с публикации снять. Как считаете, имеет смысл реализовать пакетными запросами все описанные там варианты, а не только вариант 4, и сравнить производительность на тестовой базе? Вариант с распределением по ошибке округления точнее, но приведет к лишнему этажу в пакетном запросе, что скажется на скорости. Я так понимаю, что 3 вариант реализован в комментарии (4) Dimel
(6) иной раз изящность решения задачи (ну скажем выпендрился и написал распределение в запросе) нафиг не нужно из-за своей сложности восприятия через некоторое время.
Я сторонник не пихать все и вся в запросы без необходимости. Да и на практиче возникают ситуации и у меня были, когда нужно распределить 4 числа (БУ НУ ПР ВР) параллельно по 4-м базам (БУ НУ ПР ВР) и потом еще вывести погрешности на "чистую воду" и все проровнять (решалась задача постатейного закрытия 20, 23 счетов в БП 2.0, где субконто СтатьяЗатрат не оборотное, а потом все переделывалось под БП 3.0).
К слову в БП 2.0/3.0 стандартные алгоритмы некорректно распределяют амортизацию, когда она распределяется по способам отражения, где очень много прописано разных дробных коэффициентов. Ошибка выражается в том, что правило БУ = НУ + ПР + ВР не выполняется, а должно. Пришлось написать обработку выравнивающую положение дел уже после расчета и распределения амортизации.
Увы, но переписка с 1С ни к чему не привела, они тупо отписались, что не смогли воспроизвести ошибку. хотя все предоставлял им.
(7) Brawler, Все зависит от задачи. Пихать в запросы все подряд смысла нет, когда объемы обрабатываемых данных относительно невелики. Или когда задача разовая. У меня речь идет об огромных массивах, обрабатываемых ежедневно. Речь идет о конфигурации для ЖКХ и распределении оплаты коммунальных услуг по статьям по каждому лицевому счету. "Не смогли воспроизвести ошибку" - обычное дело :)
(6)
Зачем снимать? ) Пусть будет бесплатный вариант для тех, кто хочет не особо разбираться в теории, а взять чистый практический пример.
Как ни странно, в Интернете я похожего решения не нашел, везде пишут "запросом невозможно, делайте в цикле".
Gadzhalik; Никс; dhurricane; Балабас; Simonov_NPM; pavlov_dv; user1035175; BigB; acanta; Kinestetik; Franchiser; Somebody1; pm74; mifka186; vinni_pooh; Жолтокнижниг; VVi3ard; lx@; slavap; PythonJ; Alien_job; + 21 – Ответить
(4) Dimel, Действително плохо искал. Такое простое и изящное решение, мог бы и сам додуматься. Можно ссылку, откуда это? Здесь на Инфостарте есть? Хотелось бы добавить в статью, но без ссылки на источник некрасиво будет.
(10)(10) Dimel, а зачем так сложно с тета-соединением и вычитать потом его ? Не догоняю. так тоже работает
(14) rozer, Попробуй своим запросом распределить 10 на 3 равные части (куда у тебя ошибки округления денутся?).
(16) rozer, Смысл заключается в том, что ошибка округления накапливается и учитывается по мере распределения. Попробуй расписать процесс в числах с распределением, например, 20 на 7 одинаковых строк. Обрати внимание на распределение последней строки. Туда попадает весь остаток, независимо от доли. По аналогии происходит и в предыдущих строках.
За вот - такие решения в рабочих конфигураций хочется бить по башке и крайне сильно.
Желаю вам приятного геммороя при раскапывании проблем, возникающих при вкрячивании таких запросов например в проведение документов (реверанс в сторону 1С).
(12) urrymca,
За подобные запросы в проведении документов действительно надо бить по голове. Все суммы должны быть рассчитаны до проведения и сохранены в табличной части документа. Динамический расчет при проведении запросом или кодом породит серьезную проблему при необходимости перепровести документы. Особенно если у них последовательность проведения изменилась. Причем здесь само решение? Задача поставлена распределить. Задача решена. А если кто-то вставит это в проведение - сам виноват. Я больше вам скажу, в той нетиповой конфигурации (за авторством КАМИН), с которой я в данный момент работаю именно так и было реализовано. Не запросом, правда, а кодом. Крайне запутанным, кстати. Но это еще полбеды. Эти ребята предусмотрели два варианта проведения. С распределением сумм до проведения и сохранения в табличной части с возможностью коррекции. И с распределением во время проведения. Мало того, что перепроведение такого документа было черевато. Так еще и код распределения был в двух разных местах продублирован. Распределение при проведении - в модуле документа. А распределение на форме - в модуле формы. И код этот чуть-чуть отличался. Видимо в какой-то момент исправили небольшую ошибку в одном из вариантов, а во втором - забыли. Что при этом происходило, думаю, объяснять не надо.
А сам запрос прекрасно будет жить в рабочей конфигурации. Замечу, что при решении типовых задач никоим образом не будет лишним воспользоваться заранее придуманными алгоритмами. И это касается не только 1С. Если задача трудоемка и существует алгоритм, позволяющий увеличить скорость решения в разы, то им можно и нужно воспользоваться. На то он и существует. Это, кстати, сравнительно простое решение. Бывают гораздо более сложные. Разбираться в его коде при этом можно только один раз - когда первый раз увидел. Или вообще не разбираться, если источнику доверяешь. Главное знать, где его границы, где входные данные и где результат.
А что делать, если есть еще одна группировка. И нужно распределять внутри группировки
Т.е. если добавить к примеру в задаче контрагента. И распределять долг контрагента по его договорам?
В общем и целом написать данную статью подвигла меня очередная лекция на тему себестоимости. Кстати, крайне рекомендую курс для ИТ-менеджеров в открытом университете, который там сейчас находится в открытом доступе.
Итак, классика!
Суть в том, что везде, где я встречаю код распределения (размазывания) одной суммы на другую по некому базису, всё всегда сводится к нахождению коэффициента распределения (когда мы делим распределяемую сумму на сумму базы) и последующего умножения этого коэффициента на базу по строке (например, если мы распределяем пропорционально количеству, то на количество).
Таким образом все сводится к такому вот методу:
Здесь базой является количество, сумма базы = 6, распределяемая сумма = 100. Коэффициент = распределяемая сумма / сумма базы = 100 / 6 = 16,(6) ("Шесть в скобках" - это то, как нас учили записывать периодичские дроби. Если кого-то учили иначе - проьба иметь это ввиду). Далее в каждой строке я округляю результат до копеек.
В принципе мы получили то, что хотели - распределили нужную сумму пропорционально количеству. В данном случае у нас крайне удачно получилось с округлением - в первой строке мы округлили вверх и получили одну лишнюю копейку, во второй строке мы округлили вниз и потеряли копейку. И то, что нам так повезло - это воля парня, сказавшего парню из эпиграфа сказать древним грекам все те умные вещи, о которых он им сказал.
Давайте рассмотрим случай, когда тот парень был к нам не так благосклонен, а именно - давайте распределим 10 на 3:
В итоге у нас не хватило одной копейки. Для того, чтобы решить эту проблему, необходимо учесть остаточек в конце. У нас распределенная сумма получилась равна 9,99, а сумма, которую нужно распределить - 10. Разницу, обычно, добавляют к последней строке. Т.е. в последней строке у нас будет 3,34, "чтобы не нарушать отчетности" (с).
Все хрошо, пока потерянная в ходе округления сумма мала и не играет большой роли. Но если мы попытаемся таким же образом распределить 10 на 30 строк, то внезапно окажется, что к последней строке нам нужно прибавить уже не 1 копейку, а 10. Можно, конечно, прибавить сумму остатка к последней строке:
В последней строке в итоге будет сумма 0,33 + 0,10 = 0,43. Если мы распределяем какие-нибудь ксвенные затраты на количество выпуска, то для каждой статьи затрат может набраться весьма большое отклонение, которое все целиком упадет на последнюю строчку. Таким образом продукт, выпущенный нами в последнюю очередь, вберет в свою себестоимость все те отклонения и станет "золотым" )))
Если мы будем дораспределять остаток, то, в принципе, мы также можем попасть на округление и дораспределять нам придется до тх пор, пока все копейки не израсходуются. Это, как мне кажется, несколько неудобно, непрозрачно да и затратно.
Новое решение!
Давным-давно, кажется в позапрошлую работу, меня попросили создать обработку, которая бы перекраивала контуры полей, перераспределяя на их новую площадь какие-то старые остатки на счетах учета затрат на дату распределения. Там как раз сумма распределялась между новыми площадями пропорционально новому метражу. Звучит пространно, но примите на веру (как древние греки), что это относится к обсуждаемой нами задаче распределения суммы по базе. И тогда я как раз "родил" (ага, прям как Авраам Исаака) алгоритм распределения, после которого нет остатка. Странно, но тогдашний мой руководитель так и не понял суть алгоритма, хотя после теста сказал, что все работает и оставил как есть. Западные программисты в таких случаях просто стараются не использовать подобные алгоритмы, так что честь и хвала программистам российским, которые используют и то, в чем не понимают )))
В принципе все просто: мы каждую итерацию должны пересчитывать коэффициент распределения. Давайте построим таблицу с 30-ю записями и добавим колонки для нового коэффициента и по-новому распределенной суммы:
Таким образом у нас больше нет остатка!
Через практическое мессианство! Или перейдем на ты к практике.
Давайте попробуем написать код на языке 1С, который бы распределял сумму ппропорционально базовой колонке таблицы.
Вот такой вот незамысловатый код получился. И можно забыть про контроль остатка нераспределившейся суммы.
В качестве постскриптума.
Этот алгоритм был навеян мне целочисленным алгоритмом построения линии, т.к. в нем Х распределяется на У (или наоборот - при оптимизации вообще пишут два варианта, учитывая, какое смещение больше - по Х или по У).
17 правил для составления оптимального ЗАПРОСа к данным базы 1С 44
Для формирования и выполнения запросов к таблицам базы данных в платформе 1С используется специальный объект языка программирования Запрос . Создается этот объект вызовом конструкции Новый Запрос . Запрос удобно использовать, когда требуется получ PostgreSQL: установка, настройка, обслуживание 11
PostgreSQL напрямую "из коробки" применяться для использования с 1С Предприятем не может. Необходима именно адаптированная версия от 1С, превращающая PostgreSQL в блокировочник, причем нужно понимать, что блокировки будут накладываться на всю таблиц Автоматическое резервное копирование 1С:Предприятия в облако с помощью ПО Effector Saver 3
Всем известно, для большей гарантии восстановления важных данных, необходимо копировать архивы в несколько мест хранения. Отдельный диск может помочь в случае порчи основного, но в случае если устройство будет потеряно или украдено, он будет так же Автоматическое резервное копирование 1С:Предприятия в облако с помощью ПО Effector Saver 0
Всем известно, для большей гарантии восстановления важных данных, необходимо копировать архивы в несколько мест хранения. Отдельный диск может помочь в случае порчи основного, но в случае если устройство будет потеряно или украдено, он будет так же Ввод договоров ГПХ в ЗУП (счет 76) 9
Часто меня спрашивают: Как правильно отразить договор ГПХ в ЗУП? Ниже небольшая, последовательная инструкция: Прием на работу Сведения о физическом лице, выполняющем работы по договору подряда, должны быть внесены в справочник Сотрудники организ Посмотреть все результаты поиска похожих
Еще в этой же категории
Перевод из Десятичного в Двоичное и обратно 1
При разработке конфигураций, особенно если это обмен с сайтами или старыми системами учета, приходится переводить числа из одной системы исчисления в другую. Ниже примеры кода позволяющие выполнить данные функции перевода Десятичное в Двоичное и Дво Функция проверяет наличие в строке только цифр 0
Необходимо быть уверенными, что в строке только цифры - используйте функцию // Функция проверяет наличие в строке только цифр // // Параметры // СтрокаПроверки - Строка для проверки только цифр // // Возвращаемое значение: // Булево // Ф Посмотреть все в категории Работа с Числами
Читайте также: