Logo

Продажи в Odoo

После статьи про управленческий учёт в Системе Odoo решил написать заметку про документооборот продаж. Ведь человек, взращенный советской бухгалтерской школой, не сразу воспринимает документооборот и учет, принятый в мире, так как мир регулировался не Приказами ЦСУ СССР, а постоянно эволюционирующими бест-практисис деловой жизни. 

У бухгалтеров, не знакомых с западным учетом, возникают сложности в восприятии терминологии даже в таких простых процессах как продажа или покупка. И вопрос даже не в понятии «инвойса-счета» как такового, а в принципе непонятен механизм сейлз/перчез ордеров, инвойсов и уведомлений про отгрузку. 

Решил простыми словами описать то, как в принципе продажи организованы в ERP Odoo. Но прежде, как и всегда, минуточку истории 🙂 

История Инвойса: от Алулима до Палпатина

Сто лет назад в священных землях И̶р̶а̶к̶а̶ ̶и̶ ̶Л̶е̶в̶а̶н̶т̶а̶   Урука и Аккада (территория современного Ирака), копался немецкий археолог Юлиус Йордан. Копался он, значит, копался и вышло как в той миниатюре камеди про археолога Ивана Сергеевича Копая:

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

Так вот, с 1926 года Юлиус копал вблизи города Урук. Это город население которого в доковидные времена насчитывало 50-80 тысяч человек — почти как Бердичев, только у Шумеров. 

Вот как выглядиела территория раскопок и останки города Урук (джавы и R4-D5 просто для оживления картинки) 

Uruk

Значит копал-копал Юлиус и откопал целую охапку глиняных табличек с клинописью. Таблички оказались целые и невредимые, ведь как говорил наш президент на недавнем марафоне: «Рукописи не горят». Конечно, не горят, если они стилусом по глине выцарапаны. 

И так оказалось, что таблички-то оказались ихних черноголовых бухгалтеров, описывающие кто кому  должен и какая кому полагается маржа. Вот, например, в этом Шумерском инвойсе, которому более 5000 лет, говорится о продаже волов:

Invoice Summerian

Конечно, с того времени археологами были найдены и более ранние доказательства учёта. Например, на территории современного Конго, была найдена кость, возрастом более 20’000 лет с записями (насечками) для подсчета. 

Ну да не будем устраивать б̶и̶з̶н̶е̶с̶ ̶н̶а̶ ̶к̶р̶ бухгалтерию на костях, а пойдем дальше.

Иероним Босх в 1504 году написал картину «Страшный суд». Картина состоит из трех частей — почти как дебет, кредит и сальдо. А вот инвойс, который Босх выставил Королю Кастильи Филиппу Красивому (это тот, тип, которого часто в мемах про красоту изображают):

Invoice Philipp the Handsome

Сумма инвойса составила 36 фунтов, но Босх так витиевато описал должок, что менеджеру по закупкам пришлось распарсивать текст и на полях писать собственно сумму, которую должен по ПейПалу перечислить Босху королевский казначей.  

Далее инвойсы уже начали приобретать более стандартизированную форму.

19 столетие — в итогах видно, что с переводом валют в старых екселах тоже случались ошибки и надо было вручную пересчитывать и исправлять:

Invoice 19th century

1935 год — уже видно брендирование инвойсов, но данные все еще записываются от руки:

Invoice 1935 year

40 лет назад (в июле 1981 года) компанией Омега был отправлен инвойс одному из первых владельцев персонального компьютера:

Invoice Omega Corp.

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

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

Поэтому будут инвойсы жить со времён первого царя Шумеров Алулима аж до времени галактического крепкого хозяйственника — императора Палпатина. Правда это будут уже не инвойсы с последующей оплатой, в той форме которую мы знаем, а смарт-контракты на блокчейне с мгновенным исполнением обязательства по платежу. Ну да блокчейн и смарт-контракты — это тема моей следующей статьи, а сейчас вернемся в наше прекрасное настоящее и то, как организованы продажи в системе Odoo.

Общая схема процесса продаж  

Процесс продаж проходит определенные стадии. Я здесь не стану рассматривать лидогенерацию и CRM — это тема целой отдельной статьи, а буду предполагать, что переговорщики все начальные процессы провели ранее и между продавцом и покупателем уже существуют бизнес-отношения.

В целом схему продаж можно отобразить так:

Sales workflow

Итак, на первом этапе обычно возникает так называемая Sales Quote или Request for Quotation (RFQ), что можно перевести как Коммерческое предложение, Запрос цены, Котировка.  Это предложение от продавца или запрос от покупателя относительно возможности продать товары или услуги по какой-то цене.

Обычно кроме непосредственно ассортимента и цен RFQ может включать условия поставки и оплаты, особенности и характеристики товара, прочую информацию. Котировка не является обязательством, а служит, так сказать, для “пристрелки”.  

Может существовать как в виде формального документа, так и в виде обмена имейлами, меседжами или просто звонком:

— Алё-алё, Серёга? Привет, братуха!
Здравствуй, дорогой!
— Слушай, а почём пшеничку сегодня берете на Одессе? Только дай неторгуемую котировку, бо спешу.
— Братан, как для тебя максимум могу 140.
— Опа! А чё так?
— Так ты ж видел НДС, вообщем эти коз…ы, которые мешают нам жить и всё такое.
— Ндаа, я ж не приклею ничего с таким прайсом…
— Ну смотри, на качество могу еще пяток бакинских накинуть. Только на КАЧЕСТВО, а не как обычно.
— Услышал тебя. Вернусь.
— Давай, брат, обнял.

После того, как цена согласована, покупатель присылает продавцу Purchase Order (PO). 

Purchase Order 

Purchase Order (Заказ на покупку) — это принятая в деловом обороте форма документа, который фиксирует намерение покупателя приобрести у продавца товары или услуги. Часто PO содержит отсылку на общие условия поставки (Gеneral Terms and Conditions), которые могут быть напечатаны как на самом ордере (например, на обратной стороне), так и на сайте, или же указаны в рамочном договоре о сотрудничестве, ранее заключенном, между покупателем и продавцом.

Пёрчез Ордер (или сокращенно ПиО) это, по сути, контракт между продавцом и покупателем на продажу  конкретного количества, конкретных товаров или услуг, по указанной цене на определенных условиях поставки. Согласованный PO защищает продавца от того, что покупатель в дальнейшем откажется от оплаты или даже приемки товара, а покупателя от того, что продавец откажется поставлять товары. При этом в зарубежной практике суды согласованием считают не только подписанные сканенные ПиОшки, а даже просто ответ на имейл. 

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

Вот пример реальной ПиОшки:
 

PO_Timber

Как можно видеть, заказывается обрезная доска бука, толщиной 26 мм, влажностью не выше 12%. Два сорокафутовых контейнера около 34 куба в каждом по средней цене на объем 255 долларов/куб. Качество доски ABC. Оплата по банку против погрузочных документов. Доставка в порт Хошимин, Вьетнам. Маркировка — логотип покупателя и красные торцы на досках.  Среди пакета необходимых сопроводительных документов указываются: Коносамент, Упаковочный лист, Фитосанитарный сертификат и Сертификат происхождения. Также отмечено кто в транспортном документе должен быть указан грузоотправителем и грузополучателем. 

В ERP-системе продавца данный Purchase Order будет создан в виде Сейлз Ордера. В общем порядке механика такая: Quotation превращается в Sales Order, который уже служит нашим обязательством по отгрузке товара, указанного в согласованной ПиОшке:

 Odoo SO

При этом сейлз ордер в регистры системы записывает все необходимые данные: сколько заказано товара, сколько отгружено, на какой объем выставлены инвойсы и т.д. Это очень удобно, так как позволяет планировать нашу деятельность и видеть, что осталось поставить, на какой объем выставлены инвойсы, за счет чего висит бронь на складе и т.д. В нашем примере мы видим, что отгружен один контейнер, а фактический объем составил 34,3 куб.м. На этот же объем выставлен инвойс.

То есть Purchase Order (или Sales Order если смотреть со стороны нас как продавца) это такое себе допсоглашение к рамочному договору между вами и покупателем, в котором зафиксированы цены, ассортимент и объемы товаров или работ, которые вы должны поставить или выполнить в оговоренные сроки.

Сейлз ордер конечно же может существовать для разовой поставки, но вся его «сила» раскрывается как раз в ситуации, когда заказанное количество товаров по согласованным ценам отгружается отдельными партиями. Ведь в этом случае вашим специалистам Отдела продаж уже не надо составлять кучу екселов, созваниваться каждое утро со складом или производством, материть менеджеров по логистике, ведь все находится в одной системе и все всё видят. По опыту скажу, что менеджеров по логистике всё равно придется материть, но это делать намного удобнее через встроенный в Odoo месенджер и видеосвязь 😉

Конечно же такой документ как Заказы покупателей есть и в 1С УТП. Но давайте объективно — не так много компаний, где У-Тэ-Пэшка настроена и работает не только для бухгалтеров, а еще и для отдела продаж, склада. И то, если 1Ску и настроили для всей компании, то небухгалтера на перекурах плюются, так как им не нравится интерфейс. Поэтому:

Fuck You 1С

 

Мало-помалу мы и подобрались к инвойсам.

Invoice

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

И вот здесь скажу вам, что и 1Сные счета-фактуры на самом деле не настоящие счета-фактуры. Потому как они не делают проводок. Бухоперации по реализации делает другой документ — «Реализация товаров и услуг», а счет-фактура появился в рф как налоговый документ — наша налоговая накладная. А далее переполз во все локализации, включая Украину. В Украине этот документ должен был бы называться просто «Рахунок», а не «Рахунок-фактура». Если это документ для авансовой оплаты за будущие товары, то нет там никакой фактуры. Она (фактура) появляется только тогда, когда документ счет сопровождает собой поставку физических товаров и вот в этом случае документ Накладная не нужна — есть одновременно в одном документе и основание для оплаты — Счет и основание для принятия товаров на склад — Фактура. Так и поставки, которые отправлены без сопровождающей документации, назывались в ссср — неотфактурованные. Поэтому называть счет для оплаты фактурой некорректно. Ну да маємо шо маємо. 

Итак, в международном бизнесе для отражения бухгалтерских проводок существует документ Инвойс, который и отражает хозяйственную операцию на бухгалтерских проводках. 

Invoice Odoo

Но если говорить взрослее, то существуют такие понятия как инвойс-проформа и инвойс-фактура (он же коммерческий инвойс, он же просто инвойс).

Proforma Invoice — это документ, который выставляется заранее и служит основанием для оплаты, но не является документом для отражения хозопераций в учете. То есть это как наш обычный Счет для того, чтобы клиент по нему заплатил. В Odoo инвойс-проформа отсутствует. Вернее так — он есть, но лишь в печатной форме:

    

А было бы удобнее, если бы существовал отдельный документ. И тогда бы цепочка документов выглядела так: Sales Order > Invoice Proforma > Invoice (он же Commercial Invoice, он же Invoice).

Ведь существует много бизнесов, где счета выставляются наперед, а услуги или товары предоставляются в следующих периодах.

Тем более и зарубежные поставщики часто просят, как основание для оплаты, высылать им проформу инвойс, а не просто сейл ордер. Да и отслеживать бы обязательства по своевременному исполнению оплат было бы легче, так как стандартный эйджинг-репорт строится на инвойсах-фактурах, то есть документах, которые двинули проводки, а на на сейл ордерах:

Aging report

В Odoo конечно существует механизм предоплаты, когда вы выставляете инвойс на авансовый платеж. При этом создаются проводки по реализации на такой продукт как «авансовый платеж», который потом из обычного инвойса минусуется. Но это неработающая тема, так как есть два момента:

  • некорректно отражать у себя реализацию по выставленным авансовым счетам, максимум это проводка: дебет «Ожидаемые деньги» — кредит «Дебиторская задолженность» на сумму причитающейся предоплаты;
  • клиент хочет видеть печатную форму инвойса с ассортиментом, а не с товаром «авансовый платеж»  (downpayment).   

Местные Odoo разработчики создают в самом Сейлз Ордере печатную форму Счета-фактуры (при печати слова «фактура» меня #аштрясёт от негодования). Но это неидеальное решение, так как под один согласованный ордер может быть несколько поставок, а вся моща Сейлз Ордера, как агрегатора долгов продавца по отгрузкам, как раз и раскрывается в таких ситуациях.

Теперь перейду к документам поставки.

Delivery dockets

На наших землях, долгое время пребывавших в дружественных объятиях плановой экономики, поставку товаров сопровождал такой документ как «накладная». В накладной обязательно указывался ассортимент отгруженных товаров, их количество, цена и стоимость. В западном мире для сопровождения поставки выступают такие документы как: Delivery note, Packing list, Delivery docket и т.д.

Все это по сути разновидности названия одного и того же документа, который сопровождает отгруженную партию товара в рамках конкретного Заказа (Purchase Order).

Однако, в отличии от нашей накладной, delivery-документ не имеет цен.

В отсутствии цен есть определенная логика — сотрудники склада и перевозчики видят товары, но не видят цены, с помощью которых вы идёте к успеху. Это особенно важно в операциях дропшиппинга — когда ваш поставщик со своего склада, минуя ваш склад, отгружает товары напрямую на склад вашего покупателя.  

Работая с цивилизованным миром, вы можете встретить еще такой документ как Advance Shipping Notice (ASN или по-простому АЭсЭнка). Это электронный документ, который поставщик отправляет электронными средствами связи, например, через EDI системы электронного документооборота или просто на ваш имел. ASN приходит к вам задолго до того, как приплывет контейнер из Китая с Huawei, обозначенными в ГТДешке как упаковочная пленка весом в 10 тонн. АЭсЭн служит не столько, для того чтобы облегчить вашим сотрудникам ручную набивку данных в складскую систему, сколько для того, чтобы вы ЗАРАНЕЕ планировали свой склад и работы, которые предстоит сделать в момент приемки товара. 

Вот примеры того, как выглядят сопровождающие груз документы в виде бланка и электронного документа в Odoo:

 

Вот под эти документы (на отгруженное количество) и должен выпускаться инвойс и отправляться клиенту.

В Odoo кстати есть две возможности выписки инвойсов — на отгруженное и на заказанное количество. Вроде бы удобно — система не дает возможности сформировать инвойс из сейлз ордера если не было отгрузки, но мы то с вами взрослые люди и понимаем, что всяко может быть. Поэтому рекомендую ставить галочку в настройках на основании «заказанного», а не «отгруженного» количества, чтобы иметь пространство для эккаунтинг манювера. 

В Odoo в инвойсе есть так называемая «дата учета», которая является также и датой документа — фигурирует в печатных формах. Однако вы можете отгружать товар на условиях не EXW, а CIF, DAP, DDP (тобто с доставочкой). А значит вы должны отразить реализацию не в момент, когда завсклад Михалыч зайдет к вам и скажет: «Всьо, Канстантінич, отправили нарешті», а в момент, когда все риски на товар перейдут к покупателю, как того требует МСФО.  А значит до момента получения товара покупателем на его складе (или в порту) вы должны просто переместить товар со своего склада на склад товары в пути. И поименовать транзитный склад именем того перевозчика, который ваш товар везет, бо при большом количестве отгрузок туда-сюда потом не соберете в кучу: где, кто, что, там когда «уронил». А вот после вручения товара (или распорядительного документа на него) уже надо отразить проводки по реализации и дебетовать расчеты с покупателем.

Корректировки 

В бизнесе может оказаться так, что ты отгрузил, скажем, доску бука клиенту оговоренного в PO качества, а клиент присылает тебе фотки разгрузки контейнера. А на фотках видно, что сверху пачек положено пару досок нормального качество, а ниже — трухлявые дрова. И в этот момент ты понимаешь, что твой завсклад в Дії не просто для теста оформил своего ФОПа с КВЭДом «Оптова торгівля деревиною». Что происходит в этой ситуации внутри компании я описывать не буду, а расскажу про финансово-бухгалтерский аспект. 

В данном случае мы имеем недопоставку товара, указанного в инвойсе, а значит надо провести коррекцию. В мировой практике для проведения корректировок взаиморасчетов служит такой документ как Credit Note (Кредит-Нота). 

Во внутренностях Odoo этот документ выглядит так (не смотрите на корявое англо-русское название — в Odoo так часто: когда вышла новая версия, то все баги исправляются аккурат к выходу следующей новой):

Credit note 

Кредит нота — это уведомление о том, что вам нужно кредитовать у себя счет покупателя, показывая, таким образом, свой долг перед ним (ну или уменьшая — кредитуя — его долг перед вами). То есть, в случае недопоставки, не переделывается инвойс задним числом, а выписывается корректирующий документ — Кредит-нота. Это можно сказать аналог 1Сного документа «Возврат товаров от покупателя» в части уменьшения сумм дебиторской задолженности. 

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

Odoo из коробки, как вы понимаете, для этого не подходит — надо дорабатывать. Я в своей практике пришел к тому, что наиболее понятный (чтобы было без двузначностей) механизм — это указывать в документе колонками: что изначально было в инвойсе (количество, цена, сумма), каковы данные после коррекции (количество, цена, сумма) и математический результат разницы — разнесенный в колонки — это должно быть кредитовано или дебетовано по счету клиента. Вот пример:

 

Коррекции в процессе продаж могут возникать не только в отношении поставленных (инвойсированных) товаров, но и на то, что было заказано, то есть коррекции Sales/Purchase Ордеров. Как вы можете догадаться, из коробки в Odoo такого механизма нет. То есть вы можете, конечно, отменить утвержденные Заказы, залезть внутрь, чё-то там поменять задним числом, закрыть и опять пройти всю цепочку документов. Но это уже какое-то, простите меня за ругательство, 1Сное поведение получается. Если пользоваться сейлз ордерами по-длинному (то есть с временным разрывом между оплатами и поставками, несколькими отгрузками в рамках одного ордера и т.д.) то надо делать доработки. А за доработками надо обращаться к специалистам, о которых я писал в прошлой статье

Вместо эпилога

Помните тот мем с котами «Вы рыбов продаёте? Нет просто показываю»? Там мужик котам сказал, что он рыбу не продает, хотя видно же, что продает. Почему так догадываетесь? Бо коты не его целевая аудитория — денег у них нету. Желание и рыбку съесть и… есть, а денег на это нет. Так часто и в отечественных бизнесах: желание получить ERP есть, а денег в него инвестировать — не есть.  Собственники живут часто в своих самодельных мета-вселенных и не понимают, что ERP это не для бухгалтеров — это для жизни бизнеса.

Внедрение ERP это дорого, долго и тяжело, но это надо делать, так как Data это то, что скоро станет самым главным конкурентным преимуществом. Большинство компаний из списка Fortune уже имеют в своем штате должность Chief Data Officer, а это главный по данным в бизнесе. Согласно прогнозам, стоимость экономики данных в Евросоюзе к 2025 году возрастет до более чем 550 миллиардов евро, что составит 4% от общего ВВП (по данным вышедшего на прошлой неделе Global Skill Report от Coursera). А так как «Україна — це Європа» то нам важно не отставать от цивилизованного мира.  

Поэтому надо осуществить ПЕРЕВОРОТ прежде всего в своей голове и принять решение про инвестиции в развитие данных вашего бизнеса. Как говорят на Техащине:

Наращивай BigДату и живи богато!

А как сделать это без ERP системы? Это всё равно, что видеть моркву на городі и буряк в АТБ и думать, шо у тебя дома на столе борщ. Поэтому начинайте инвестировать в ERP системы, кто побогаче — в MS Business Central, ну а кто поприжимистей — увидимся в Odoo 🙂