Мы рассмотрели архитектуру HubCloud.io. Теперь можно описать подходы к решению учетных задач.
Чтобы описать подходы к решению учетных задач, нужно сами эти задачи как-то классифицировать. После этого можно будет сказать, что все (или почти все) задачи можно решать на том или ином инструменте.
Давайте попробуем систематизировать, эти варианты, схемы, способы расчетов. По-нашему, мнению, существует семь типовых задач (и семь подходов к решению учетных задач). Все другие могут быть приведены к этим подходам или методам.
(!) Данная классификация не является строгой. Возможно, что список не полный. Но, как мы уже писали неоднократно, что цель статьи и курса - получить прикладной навык в решении учетных задач, поэтому считаем возможным применять эмпирические выкладки.
Это:
- метод “оборотов-и-остатков”
- “метод расчет среднего”
- “метод распределения по удельному весу (по базе распределения)”
- “задача разукомплектации”
- “задача получения актуального списка”
- “задача установки связи”
- “задача партионного учета”
Приведем примеры для каждого из методов.
- метод “оборотов-и-остатков”: основные финансовые отчеты (ОПУ, ДДС, Баланс), любые взаиморасчеты, складской учет, ячеечный учет на складе, цепочка поставки, контроль бюджета и пр.
- “метод расчет среднего” - списание себестоимости по средней, расчет стоимости 1-го дня при начислении ЗП и пр.
- “метод распределения по удельному весу (по базе распределения)” - распределение стоимости транспортировки на товар, распределение общих расходов на выпуск и пр.
- “задача разукомплектации” - расчет потребности в комплектующих и пр.
- “задача получения актуального списка” - начисление заработной платы, актуальный список арендаторов и пр.
- “задача установки связи” - цепочка поставки, база знаний по контрактам и пр.
- “задача партионного учета”: списание себестоимости по партиям, суммовая разница, рублевая себестоимость при платежах в валюте разными траншами, погашение траншей ВКЛ (возобновляемая кредитная линия) и пр.
Рассмотрим решение каждого метода на примере.
Метод “оборотов-и-остатков”:
Описание подхода.
Этот подход в учете применяется очень широко. Всегда, когда вы говорите словосочетание “сколько осталось...” - это означает, что вы применяете данный метод. Взаиморасчеты с поставщиками, клиентами и персоналом, учет денег, учет товаров и материалов, задача контроля бюджета и даже задача ячеечного учета на складах относится к "методу оборотов-остатков". И многое-многое другое. Частным случаем данного метода является двойная запись в бухгалтерском учете, и формирование три основных финансовых отчета: ОПУ, БДДС и Баланс.
Рассмотрим пример, существует некая компания-импортер, которая осуществляет поставку морскими контейнерными перевозками. Поставку можно разделить на 5 этапов (по принятому в данном виде деятельности документообороту).
(1) заказ → (2) инвойс → (3) пакинг-лист → (4) коносамент → (5) таможенная декларация → (6) доставка порт-склад
Заказ - это оформленная юридическая договоренность, о запуске в производство. Длительность от заказа до поставки на склад примерно 5 месяцев.
Инвойс - выставленный заводом счет, который означает, что товар заводом произведен и через короткое время будет отправлен в порт отправки (заказ↔инвойс (1:n)).
Пакинг-лист - документ погрузки в контейнер и на борт корабля (инвойс↔контейнер (n:n), пакинг-лист↔контейнер (1:n))
Коносамент - документ на право получения груза в порту, означает, что до прихода товара в порт 3- 5 дней. (коносамент↔пакинг лист (1:n)).
Таможеннаядекларация - груз прошел границу и через 3 дня будет на складе. (таможенная декларация↔коносамент (1:n)).
Доставка порт→склад - товар доставлен из порта прибытия на склад (n:n).
Цепочка поставки (от заказа до прихода на склад) занимает пять месяцев. За такой длительный срок могут происходить временные сдвиги, то есть товар может прийти и раньше и позже. Это может очень усложнить жизнь компании (или пустые полки или денег на оплату товара нет, так как “все деньги в товаре”). Поэтому задача учета такой компании в том, чтобы “видеть” цепочку исполнения на всем протяжении поставки.Чтобы решить данную задачу, мы посчитаем разницу между парами соседних Операций.
➢01.Заказ “минус” 02. Инвойс
➢02. Инвойс “минус” 03. Пакинг-лист
➢03. Пакинг-лист “минус” 04. Коносамент
➢04. Коносамент “минус” 05. Таможенная декларация
➢05. Таможенная декларация “минус” 06. Доставка порт→склад
➢06. Доставка порт→склад
Что нам это дас
т? Давайте для примера рассмотрим, пару “01.Заказ “минус” 02. Инвойс”. Пусть компания заказала 100 единиц товара, а инвойс (выпуск продукции с завода) - на 80 единиц. Что это означает?
Это означает, что поставщику осталось (слово “остаток” - это индикатор) изготовить еще 20 единиц товара. См. таблицу ниже.
Следующая пара Операций, 02. Инвойс “минус” 03. Пакинг-лист. Инвойс (выпуск с завода) равен 80 единиц, а пакинг-лист (погрузка на корабль) 70 единиц. Что это означает?
Это означает, что 10 единиц осталось в порту. См. рисунок ниже. Как и в прошлом примере мы можем легко получить эти данные, просто сгруппировав таблицу (“Сводная таблица” в Excel). См. ниже.
Следующая пара Операций. 03. Пакинг-лист “минус” 04. Коносамент. Что означает, что в на корабль было погружено 70 единиц товара, а в порт прибытия этот груз еще не пришел? Это означает, что груз еще в океане. См. рисунок ниже.
Мы рассмотрели три Журнала из шести, но все остальные Журналы будут работать по аналогии. Первая Операция записывается с «+», а вторая с «-». Разница между ними показывает остаток, который находится в “этом звене”.
Теперь изобразим это в виде схемы. Операции на ней (на схеме) изображены синимиэллипсами, а Журналы желтыми прямоугольниками. Записи Операций в Журналахзаписываются с разными знаками, и обозначаются красными (минус) и зелеными стрелками (плюс).
Три (из шести) Журнала изображены подробно (ниже под желтыми прямоугольниками). Три, а не шесть, просто чтобы не загромождать рисунок, так как метод расчета будет понятен и на трех Журналах.
Теперь нам достаточно поместить данные по остаткам в одну таблицу-отчет, и в ней мы увидим всю картину по данному заказу. См. рисунок ниже. Очевидно, что в отчеты можно добавить планируемые даты прихода и тем самым прогнозировать приход товара на 5 месяцев вперед. Можно добавить в отчет планируемые и фактические даты и тем самым контролировать исполнения обязательств поставщика.
(!) Мы применили схематичное отображение взаимосвязи Операции и Журналов. Как и в случае со схемой ER-модели - это удобный инструмент моделирования учета. Он позволяет видеть, в какой Журнал Операция делает запись, с каким знаком (+ или -) и откуда Операция получает данные для расчета. Назовем этот инструмент - “схема журнал-операция” и в дальнейшем будем использовать для описания или моделирования учета.
(!) Все указанные в примерах“схемы журнал-операция” - это не единственный вариант решения. Например, с морской поставком, возможно, что кто-то с другими предпочтениями попробует поместить все данные в один Журнал, и те же остатки будет считать налету в отчете. Вариантов решения одной и той же задачи может быть очень много и панацеи нет. Наверное, самое важное в конструировании “схемы журнал-операция” - это воображение. Навык представить, что будет с происходить с данными в вашей схеме.
“метод расчет среднего”.
Описание задачи.
Расчет среднего, также часто применяется в учете. Например, при расчете заработной платы, для расчета "средней стоимости рабочего дня". Расчет “средней” может применяться при расчете среднего курса покупки валюты для пересчета в рублевую себестоимость. Калькуляционные расчеты, в которых считается средняя стоимость единицы калькуляции. Но чаще всего данный метод применяется при расчете себестоимости товара "по средней".
Рассмотрим пример торговой компании. Компания купила две партии товара:
- 100 единиц товара по цене 50 руб/ед
- 100 единиц товара по цене 100 руб/ед.
Решить эту задачу можно двумя вариантами.
Вариант первый, все расчеты сделать в Операции продажи. Смотри таблицу ниже.
При продаже 100 единиц товара, Операция “Продажи” получает остатки (количество и сумму) товара из Журналы Товары, и считает среднюю стоимость. См. рисунок ниже.
Давайте изобразим для данного варианта, ее “схему журнал-операция”. См. ниже на рисунке.
Второй вариант реализации.Так как первичные документы прихода товара (с точной ценой) могут вноситься позднее продажи, то можно в Операциях продажи вносить только количество товара, а себестоимость рассчитывать в конце месяца. Тогда в течении месяца ситуация будет выглядеть так, как изображено ниже на рисунке.
А после окончания месяца Операция Закрытия месяца сделает следующие расчеты:
- Выберет все Операции продажи закрываемого периода
- Автоматически построит таблицу с этими Операциями
- Для каждой номенклатуры товара получит остатки товара на начало периода, плюс приходы товара за месяц в рублях и в количественном выражении.
- В Операции посчитает, среднюю себестоимость за период
- И умножит среднюю себестоимость на количество проданного в Операции, получив стоимость списания в рублях
- И наконец – сделает записи в Журнале (дописав в него сумму). См. рисунок ниже.
(!) Все эти расчеты осуществляются «выражениями и формулами»: получи перечень всех операций за месяц, получи остатки по номенклатуре и т.д.
Изобразим “Схему журнал-операция” для этого варианта расчета. См. рисунок ниже.
“метод распределения по удельному весу (по базе распределения)”
Описание задачи. Данный метод применяется в учете очень широко. Распределение косвенных и постоянных затрат на себестоимость продукции - это относится к данному методу. Или даже прямые, но которые нельзя учесть, например, в одном цеху производится два вида продукции, и потребленную электроэнергию делят между ними в какой-то пропорции, или когда в зависимости от времени загрузки сотрудника (которую он указал субъективно) его заработную плату распределяют на несколько проектов.
Рассмотрим пример, компания приобретает товары и осуществляет доставку сторонним транспортом. Стоимость доставки должна быть распределена на стоимость товара (база распределения - стоимость товара).
Существует два варианта реализации. Вариант первый – сделать расчеты непосредственно в Операции ”Поставка”.
Для этого в таблицу Операции нужно добавить поле для расчета доли (сумму в строке / сумму итого в колонке). После расчета доли автоматически рассчитается сумму “за доставку”. См. на рисунке ниже.
“Схема журнал-операция” изображена на рисунке ниже.
(!) Кстати, так будет выглядеть “двойная запись” на “схеме журнал-операция”.
Второй вариант, это сделать Операцию “Транспортировка” – отдельной операцией. См. “схему журнал-операция” на рисунке ниже.
В Операции “Транспортировка” в ТаблицеОперации выбирать перечень “Поставок товара” к которым относится данная транспортировка.
После окончания месяца создавать Операцию “Распределение транспортных расходов на стоимость товаров”.
Операция получит данные по поставкам и товарам в этих поставках (стрелки 3). Произведет расчет и допишет суммы на каждую номенклатуру товара (стрелка 4). И после этого запишет в Журнал “затраты по транспортировке”() суммы затрат с минусом, тем самым сделает невозможным по ошибке распределить сумму “за доставку” еще раз.
(!) Схема решения будет отличаться в зависимости от того, как будут сочетаться "Поставки" и "Доставки", возможно, что распределе нпоэтому не представляем
“задача получения актуального списка”
Описание задачи. Задача получения актуального списка, широко применяются в учете. Например, курс валюты, на дату, или актуальный руководитель подразделения (которые могли меняться много раз за время существования подразделения).
Решаются тремя разными способами. Если актуальных элементов может быть много, то это делается присвоением статуса: "актуально/не актуально“ и автоматическим отбором списка со статусом "актуально". Если актуален только последний, то используется специальное выражение Last (). Это может использоваться например, для получения последнего актуального курса валюты или актуального руководителя подразделения.
Сложнее задача получения "актуального списка" сотрудников или периодических договоров, когда актуальный список должен быть получен на конец периода, а события "внутри" периода.
Рассмотрим пример, в котором компания занимается арендным бизнесом. В течении отчетного периода (месяц) происходят заключения и расторжения договоров. Требуется автоматизировать расчет начисления выручки. Выручка начисляется раз в месяц, при этом расчет должен учитывать, что будут арендаторы, которые займут помещение не с 1-го числа или освободят не в последний день месяца.
У нас есть два события: заключение и расторжение договора. Операция Заключение договора сделает записи в трех Журналах. Журнал 1 будет узлом решения задачи, именно в нем мы получим "актуальный список" договоров. В Журнале 2 мы будем хранить реальные даты заключения договоров. А в Журнале 3 мы будем хранить арендную ставку договора.
За январь мы заключили один договор с ООО “Орехи”. 10 января арендатор занял помещение, мы создали Операцию Заключение договора #1,и эта операция сделала соответствующие движения в Журналах (они отмечены синим).
Итого арендатор занимал помещение 10 дней.
См. рисунок ниже.
20 января арендатор освободил помещение. Мы создали Операцию Расторжение договора и она сделает следующие движения в Журналах (движения на рисунке отображены красным):
В Журнал 2 мы запишем дату расторжения договора - 20 января. А в Журнал 1 мы запишем дату начала следующего месяца - 1 февраля 00:00:00. Мы сманипулировали датой.
Месяц подошел к концу и мы автоматически начисляем выручку за услуги аренды.
Когда мы начисляем выручку за январь, то используя формулу Группировать (GroupBy) в Журнале Актуальные договора. Так как мы отбираем записи до 31 января, то итогом этого будет только запись +1, и результатам будет строка с договором №00-1, которая попадет в Операцию. См. рисунок ниже.
Когда мы начисляем выручку за февраль, то в Группировать (GroupBy) в Журнале Актуальные договора. попадут две строки +1 и -1, т.е результатам будет 0 и данные договор не попадет в Операцию начисления выручки. См. рисунок ниже.
“Схема журнал-операция” изображена на рисунке ниже.
“задача разукомплектации”
Описание задачи. Чаще всего этот метод применяется в планировании производства или бюджетировании, когда на основании плана производства, планируются материалы и комплектующие, которые нужно произвести или закупить. Этот же метод применяется, когда на основании заказа покупателя планируется заказ комплектующих у поставщика. Рассмотрим подобный пример.
Клиент заказывает изделие, цвет, тип поверхности и количество. Заказ клиента должен быть разукомплектован до конечного списка комплектующих, при этом должно быть учтено количество и цвет. Данная задача будет решаться с помощью Соединения таблиц. Так как мы еще не изучали подобные действия с таблицами, то для того, чтобы легче понять суть решения задачи - представим себе некую конструкцию. См. рисунок ниже.
Клиент заказал Изделие А, красного цвета, в количестве 10 единиц и синего цвета также в количестве 10 штук. При этом Изделие А состоит из нескольких деталей (Деталь 1, Деталь 2, Деталь 3, Деталь 4). Какое количество, какого цвета деталей и какой поверхности требуется произвести? См. рисунок ниже.
“Схема журнал-операция”, с помощью которой будет решена задача, изображена на рисунке ниже.
Для решения задачи потребуется какая-то функция.
(!) Действия над таблицами изучаются в "Реляционной алгебре". Без навыков работы с таблицами невозможно решить учетную задачу автоматически, невозможно автоматизировать получение отчетов и сложно иметь представление, как устроена учетная система. Подробно этот вопрос будет рассмотрен в главе 5.1 "Уровень отчетов", теория: действия с таблицами. Для решения данной задачи требуется "Левое соединение" таблиц.
Схематически изобразить решение этой задачи можно следующим образом. См. рисунок ниже.
Тоже самое делаем и с двумя другим строками заказа. В результате у нас получится промежуточная таблица. См. рисунок ниже.
Интуитивно все понятно. Взяли Изделие А (с краской и с типом поверхности) и “подтянули” к нему детали из которых оно состоит. Теперь нужно перемножить количество изделий в Заказе и количество деталей в комплектации (10 х 4, 10 х 2, и так далее). Потом убрать все ненужные столбцы. Что получится, смотрите на рисунке ниже.
“задача установки связи”
Описание задачи. Под связью здесь понимается то, что мы определили как Связь между Сущностями. Где это может применяться в учете и в управлении? Например, в рассматриваемом выше примере с "морской поставкой" нам нужно знать, все, про каждую упаковку товара: в каком он был инвойсе, в каком пакинг-листе, .. и так далее до заказа. Например, для выставления претензий перевозчику или производителю.
Пример номер два: у нас торговая компания B2B, имеющая филиалы по всей стране, и не имеющая территориального распределения клиентов между филиалами. В этом случае филиал Центр может отгружать продукцию в регион Сибирь, а филиал Сибирь в Центр. В целом это ситуация негативная, так как товар может излишне перемещаться по стране, а также потому что мы не можем вменить филиалу, что какой-то крупный клиент на "его территории" не проработан. Тогда если мы захотим от этой ситуации уйти, нам нужно будет оценивать грузопотоки [Регион-Филиал]↔[Регион-клиент].
Решаются такие задачи достаточно просто. Достаточно заполнить “плоскую таблицу” со всеми аналитическими признаками, взаимосвязь которых мы хотим исследовать. Иногда есть смысл в создании соответствующего Журнала, иногда задача решается уже в отчете, где система связывает данные.
Рассмотрим пример, когда задача решается в Журнале. Рассмотрим пример "морской поставки", которую мы рассматривали выше. Решение задачи состоит в том, что требуется протянуть через всю “цепочку” те данные, связь которых мы исследуем.
заказ №… инвойс № … пакинг-лист №…коносамент № …
() Протянуть данные в HubCloud.io можно двумя механизмами, или "вводом операций на основании” или "механизмом подбора данных”. Оба механизма не требуют повторного ввода данных, информация заполняется автоматически.
“задача партионного учета”. Данный метод используется очень широко. Возможно, что это второй по частоте метод в учете после метода "оборотов и остатков". Партионный учет применяется, когда учитывается нечто, имеющее различные параметры. Как всегда, все легче понять на примерах.
Например, у нас есть две партии товара. У этих партий разные сроки годности. Поэтому при продаже нам нужно вести учет отдельно и пока не продана "старая" партия, мы не переходим к продаже "новой".
Этот метод применяется для учета сроков погашения отдельных траншев в кредитном договоре, при перерасчете из валютной себестоимости в рублевую, когда разные транши имеют разный курс, для расчета себестоимости списания товара (если принят метод учета "не по средней"), для учета сделок по хеджированию и во многих-многих других учетных задачах.
Эти задачи решаются так: система автоматически ведет учет остатка по партии, и как только остаток партии становится равным 0, то система начинает списывать с другой партии. В Excel эти задачи не решаются. В HubCloud.io для этого существует специальная функция.
Рассмотрим, как это делается на примере морской поставки. Мы оплатили три раза по 100$, и каждый раз по разному курсу (50,60.70). Поставки были по 150 $. Нам требуется посчитать рублевую стоимость инвойса. См. таблицу ниже.
Если принять правило партионного учета, то рублевая стоимость поставки будет различной.
Инвойс №1 в сумме 150$ был оплачен Оплатой #1 в сумме 100$ и Оплатой #2 в сумме 50$. Инвойс №2 в сумме 150$ был оплачен Оплатой #2 в сумме 50$ и Оплатой #3 в сумме 100$.
См. таблицу ниже.
Операция “Оплата инвойса” запишет в Журнал “Список оплат” (стрелка 1).
Операция “Инвойс (поставка)” делает движение в Журнале “Список поставок” (стрелка 1).
Операция “Расчет рубл. стоимости инвойса” получит информацию из Журналов (стрелки 2).
В Операции “Расчет рубл. стоимости инвойса” производится расчет “по партиям” (стрелка 3).
Операция “Расчет рубл. стоимости инвойса” делает движения в Журналах “Список оплат” и “Список поставок”(стрелка 4), чтобы уже эти данные не попали еще раз в Операцию следующего месяца (обнуляет остатки)
Операция “Расчет рубл. стоимости инвойса” делает движения в Журнале “рублевая стоимость инвойсов” (стрелка 4).
Подведем итоги главы: Мы рассмотрели "уровень проводок". На этом уровне решается задача автоматизации учета. Сложные задачи всегда решаются с использованием нескольких Объектов: различных Операций, Журналов и Функций и выражений. Архитектура решения одной и той же задачи может быть различной на выбор исполнителя.
В данной главе были рассмотрены подходы к решению семи учетных задач. Решения были рассмотрены схематично. Для визуализации решения и для упрощения процесса проектирования решения мы предложили использовать "схему журнал-операция".
Как работать на практике с выражениями и функциями HubCloud мы пока не рассматривали. Теоретические вопросы действия с таблицами будут рассмотрены в главе 5.1 "Уровень отчетов", теория: действия с таблицами. Как непосредственно работать с функциями и выражениями HubCloud можно ознакомиться в инструкции. В следующей главе вновь переходим к решению СКВОЗНОГО ПРИМЕРА.