Так получилось что мне заказали перенос данных из одной системы - QuickBooks Desktop в другую систему ZOHO BOOKS и в процессе написания интеграции мне пришлось очень плотно познакомиться с этими программными продуктами. Переносили данные за 14 лет, со всей справочной информацией и документами. 

Лого
Лого

QBD (QuickBooks Desktop) – это информационная система для ведения бухгалтерского учета, созданная в США. Вообще я планирую написать статьи о двух учетных западных системах- ZOHO books и QuickBooks Desktop. В этой статье я хочу показать особенности работы и возможности этого программного продукта. Статья не является подробным обзором или инструкцией по работе с системой. Скорее, она носит ознакомительный характер для понимания того, как работают информационные системы для бизнеса за рубежом.

Введение

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

  • Из чего состоит система;

  • Каков ее документооборот;

  • Как делать проводки и создавать отчеты.

Кроме того, рассмотрю некоторые отличия этой информационной системы от 1С Бухгалтерии.

Основные элементы и принципы работы

В США и других западных странах, в принципе, нет отдельных направлений – управленческий, бухгалтерский учет и т.д. Потому и система QBD – это больше, чем просто бухгалтерия.

Здесь все основано на таком понятии, как Accounts. Если попробовать найти соответствие в нашем понимании, то это будет счет. Если мы зайдем в раздел Chart of Accounts, то увидим все имеющиеся счета и субсчета. 

Важно понимать, что счета и субсчета – это объекты со строгими  ограничениями . Они не могут быть документами или еще каким-то типом данных, отличным от понятия счет и субсчет. И еще работа в системе строится на следующем: чтобы выполнять текущую работу, нужно перейти к тому справочнику, который для этого необходим. Например, для работы с покупателями необходимо перейти в раздел Customers, и в нем создать необходимый документ. Если мы собираемся работать с поставщиками, переходим в раздел Vendors и т.д.

Система делится на 5 больших блоков:

  1. Customers – покупателей

  2. Vendors – поставщики

  3. Item – товары

  4. Непосредственно бухгалтерия, и все, что с ней связано, в том числе, зарплата.

  5. Банк.

Давайте разберемся с каждым блоком подробнее.

Chart of Accounts

Chart of Accounts - это раздел, без которого работа в системе невозможна. Это план счетов, которыми будет пользоваться компания. Но, в отличие от Российский Федерации, здесь нет жестко заданного перечня счетов. В Chart of Accounts вы сами добавляете только те счета и субсчета, которые реально нужны для работы.

Т.е. вы сами можете создать счета по собственному усмотрению. Но и здесь есть определенные ограничения. Обязательно должен быть указан Accounts Type

Как видите, количество возможных типов ограничено.

Самые важные типы:

  • Bank - все возможные банковские операции.

  • Accounts Receivables - дебиторская задолженность

  • Accounts Payable - кредиторская задолженность

  • Income - приход товаров

  • Cost of Goods Sold - себестоимость (приходная стоимость) товаров;

  • Expense - любые затраты компании

Очень важно различать между собой Cost of Goods Sold и Expense. Только при правильном распределении счетов вы сможете получить правильные проводки и отчетность.

Customers

Работа с покупателем начинается с Estimate, т.е. коммерческого предложения. На основе Estimate можно создать Invoices (счет) или Sales Orders (Заказ клиента). На следующем этапе мы можем зафиксировать оплату от клиента или произвести возврат.  

Bid/Estimate

Документ практически ничем не отличается от счетов или заказов клиента. Точно такая же табличная часть, также указываются сведения о клиенте и т.д.

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

Что можно сделать с Estimate:

  1. Выбрать шаблон для печатной формы;

  2. Отредактировать печатную форму, например, добавить текст и т.д.

  3. Сохранить в удобном формате и отправить покупателю.

  4. Создать на основе Estimate счет покупателю, заказ клиента или заказ товаров поставщику.

Customers и Invoices 

Теперь давайте посмотрим подробнее на Sales Orders

Как видите, здесь также есть все необходимые для работы сведения:

  1. Информация о клиенте;

  2. Template – шаблон печатной формы;

  3. Наименования товаров, цены, количество;

  4. Необходимая служебная информация.

Практически также выглядит и счет (Invoices). Потому мы и рассматриваем их в комплексе. 

Обратите внимание, что Sales Orders ничем не отличается от Invoices, кроме одного важного момента. На основании Sales Orders система резервирует товары.  А Invoices – это финансовый документ, который фиксирует задолженность клиента.

В любом из документов есть возможность быстрого перехода в такие отчеты:

  1. Быстрый отчет по клиенту;

  2. История транзакций по документу;

  3. Проводки документа;

  4. Налог по документу и т.д.

После создания и проведения Sales Orders на его основе можно быстро оформить Invoices. Таким образом, мы сначала зарезервировали товары, после чего можем спокойно выставить клиенту счет и зафиксировать его задолженность.

Далее, как обычно, получаем оплату, проводим полученную сумму и т.д.

Здесь важно понимать, что в отличие от привычной для многих 1С, в QBD нет разделения по договорам. Здесь мы можем фиксировать суммы на основании счетов, а взаиморасчеты выполняются только по покупателям в целом.

Customer payments/resift payments

После того, как был зафиксирован Invoices, на его основании можно провести оплату от клиента. Для этого создается документ Customer payments. Здесь мы можем зафиксировать точную сумму оплаты, а также указать способ получения средств. Методов система включает много: наличные, чек, оплата кредитной картой и т.д.

После выбора клиента на экране Customer payments в нижней части отображается список инвойсов, открытых для указанного контрагента.

Чтобы оплата прошла корректно, необходимо обязательно выбрать, что именно, какой из инвойсов оплачивает покупатель. При этом сама сумма оплаты может быть любой. Например, если у нас счетов выписано на 600 долларов, а оплата пришла на 500 долларов, мы так и проводим. При этом один из счетов будет оплачен только частично.

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

Vendors

Работа с поставщиками выглядит практически так же, как и с покупателями, только, соответственно, здесь уже наша компания выступает в роли заказчика. Первым делом формируется заказ поставщику - Purchase Orders. Далее, на его основании Receive Inventory (документ, подтверждающий прием товара на склад). А потом на основе выставленного заказчиком документом – Bills. В нашем понимании это счет на оплату. Но, на самом деле, Bills - это нечто большее.

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

Bills можно отправить на оплату непосредственно из документа или выбрать группу Bills, которые вы планируете оплатить. Каждая оплата поставщику проводится только на основании Bills, другие варианты система не позволяет. Потому, если вы выполнили оплату, приложили чек или какой-либо другой документ, можно быстро и просто формировать взаиморасчеты и выполнять сверки.

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

Еще один интересный момент - на основании Bills  можно сформировать Invoices для своих покупателей. Т.е. если вы выполняете какие-то посреднические услуги или перепродаете товары, такая функция очень удобна.

Item

Справочник Item – это перечень всех товаров с их атрибутами. Этот раздел почти не отличается от любой другой системы, предназначенной для работы с товарами, в том числе, 1С.

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

 

Дело в том, что в понятие Item входят не только товары. Это могут быть услуги, скидки, группы товаров и т.д. В зависимости от выбранного типа элемента, меняется набор параметров, которые необходимо будет заполнить.

В большинстве типов Item важными параметрами являются:

  1. Себестоимость;

  2. Цена продажи;

  3. Cost of Goods Sold (тип «цена продажи»);

  4. Income Account (аккаунт, т.е. счет, на который будет зачисляться сумма при продаже товара).

Отчеты в системе QBD

Система предлагает обширный перечень различных отчетов. Самый главный отчет называется Profit & Loss. Об этом отчете мечтают практически все отечественные предприниматели. Он позволяет увидеть работу организации в целом со всеми параметрами, необходимыми для оценки эффективности.

Интерфейс системы

С одной стороны, интерфейс можно назвать несколько старомодным. Внешний вид невозможно изменить или настроить под себя. А его консервативность вы уже могли и сами оценить на скриншотах.

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

Интеграция с другими системами

В системе QBD имеется собственное API, которое работает надежно, но с большим количеством ограничений.

 Работает API в двух вариантах:

  1. С использованием процессора запросов.

  2. На основании модели запрос-ответ.

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

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

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

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

Важные особенности QBD

В отличие от привычного нашим соотечественникам «конструктора» 1С, в системе QBD вносить изменения на уровне разработчиков или использовать какие-то доработки и надстройки невозможно. Система продается «как есть».

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

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

В самом конце я хотел бы сделать акцент,  что выше мы изучали именно систему QBD. К сожалению, ее нередко путают с QBol – подобной американской бухгалтерской системой, но разработанной для работы онлайн. О ней я готов рассказать отдельно, если у вас появится такое желание. Хотите прочитать обзор QBol? Пишите об этом в комментариях.

Комментарии (12)


  1. mikleh
    27.08.2021 17:55

    А насколько эта система распространена? 1Ска то у нас абсолютно буквально в каждом ларьке. А как с этим в Штатах с их традиционно более либеральными требованиями к учету?


    1. ramil_trinion Автор
      27.08.2021 17:57
      +1

      А насколько эта система распространена? 

      Незнаю, со слов заказчика это чуть ли не монополист.

      А как с этим в Штатах с их традиционно более либеральными требованиями к учету?

      С чем?


    1. iliabvf
      27.08.2021 21:09

      В США и Канаде Quckbooks это как 1С в каждом ларьке


    1. liddom
      27.08.2021 21:35
      +1

      На самом деле зависит от размера компании и сложности бизнес процессов. Для "ларьков" это действительно распространненая система (хотя сейчас Quick Books Online, наверно, уже сравнима по популярности). Однако для чего-то, что немного больше ларька (например если есть производство товаров или есть какие-то техники, которые выезжают на место для проведения работ, и т.п.) существует множество других систем, вплоть до SAP для уж совсем больших компаний.


  1. Naf2000
    27.08.2021 21:59

    С одной стороны - описание системы очень поверхностное, что называется "галопом по европам".

    С другой и может быть следствием первой - ну как-то все очень примитивно для учета. Для уровня ларьков наверное годится.

    Что хорошо у них для ведения бизнеса - нет такой сложной системы контроля, или я ошибаюсь? Например есть требование вести учет товаров в разрезах ГТД? Про новые маркировки я молчу. А то что нет договоров - не могу назвать плюсом. Учет сроков задолженности есть? Расчет себестоимости по какой методике? Несколько видов цен продажи и скидки по условиям настроить можно?

    Ну и пресловутые несколько юр. лиц в одной компании. Хотя может ИМ это и не надо


  1. locutus
    27.08.2021 22:15

    Теперь понятно, откуда растут многие "ноги" в GnuCash


  1. nomhoi
    28.08.2021 03:03

    Было интересно, кто может про odoo также написать?


    1. ramil_trinion Автор
      28.08.2021 13:07
      +1

      Могу, с системой знаком. Написать?


      1. nomhoi
        28.08.2021 14:20
        +1

        Да, пожалуйста, было бы очень интересно.


    1. CrushBy
      28.08.2021 15:03
      +1

      Я разбирался в свое время с Odoo, и мы даже сделали похожее решение на основе его бизнес-логики с российской локализацией.

      В целом, по структуре документов там практически такая же логика (даже названия документов практически те же). Единственное, Odoo делает больше упор не на бухгалтерскую логику, а на управленческую.

      Но важно понимать принципиальное отличие логики учета в РФ и в западных системах. Там есть два отдельных документа Bill/Invoice (финансовый) и Receipt/Shipment (складской). Так вот с точки зрения и проводок и момента их отражения они в принципе не связаны. То есть, я могу отгрузить или принять 10 документами в разное время, а потом на все это выписать один финансовый документ.

      В российской же схеме ведения учета это практически невозможно. Точнее есть теоретически схема через складские ордера, но по проводкам там другая логика, и на практике ее мало кто использует. Например, основной документ продажи клиенту УПД содержит в себе как количественные характеристики, так и финансовые (НДС). В том же Odoo, когда вы приходуете товар через документ Receipt, то себестоимость, по умолчанию, вообще берется из заказа. А потом, если в Bill приходит другая цена, то просто разница относится на отдельный счет. Вот тут есть примеры (1, 2).


      1. nomhoi
        28.08.2021 16:08

        Я разбирался в свое время с Odoo, и мы даже сделали похожее решение на основе его бизнес-логики с российской локализацией.

        Спасибо, посмотрю. Я тут тоже ERP разрабатываю: https://habr.com/ru/post/568192/. Будем конкурировать.

        Но важно понимать принципиальное отличие логики учета в РФ и в западных системах.

        Я почитал несколько статей про различия в системах учета в России и на западе. Есть различия, есть общие вещи.

        Там есть два отдельных документа Bill/Invoice (финансовый) и Receipt/Shipment (складской). Так вот с точки зрения и проводок и момента их отражения они в принципе не связаны. То есть, я могу отгрузить или принять 10 документами в разное время, а потом на все это выписать один финансовый документ.
        В российской же схеме ведения учета это практически невозможно. 

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