Если бы вы создавали ERP систему с нуля для международного рынка, как бы вы подошли к проектированию финансового контура?

[Lemming]

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


Логично предположить, что при ограниченных ресурсах, весь земной шар не покрыть, так что надо исходить из стран Северной Америки (США, Канада) и Западной Европы(Великобритания, Германия, Франция). Как я уже писал, я хочу создать Open Source ERP для малого и среднего бизнеса и сейчас занимаюсь всевозможными исследованиями на эту тему. Страны указанные в скобках я вижу как основные рынки для коммерческой версии этой системы и мне интересно насколько в них сильно отличается финансовый учет.

Кстати, ещё одна интересная деталь заключается в том, что в открытом доступе практически нет информации по бухгалтерскому учету, причем не только Российскому, но вообще по всему миру. Кроме того, всё что касается ERP так же почти не представлено в интернете, исключение наверное составляют около-технические темы по SAP, Dynamics и Odoo. Даже по 1С практически нет ресурсов, которые бы что-то рассказывали для других профессионалов.

Это нежелание людей, занятых в этих областях, делиться знаниями наводит на печальные мысли: им нечего сказать, они боятся сказать, они откровенно жадничают. Я на полном серьезе нашел какой-то список (уже удалил) из 10 блогов по бухгалтерскому учету (западному) из них половина не открывалась, а половина вела на приглашение купить курсы. Неплохой полу-коммерческий ресурс тут, в остальном выдача забита рекламой курсов. Так что второй вопрос топика: что происходит с распространением специализированных знаний в конкретной областии и почему?

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

[cuba]

Я бы добавил еще индию и Китай)

Насчет фин. контура, так есть GAAP (как правила учета в США), да IFRS (как правила отчетности в Европе)
Так же, могу помочь "спец. издания", например, по HR, в помощь Вам, HRBOK (описание "законов\норм" под США и ссылки на них для дальнейшего детального изучения)

"Осваиваете" этот контур, а уже дальше min отличия по странам: в каждой стране есть свой свод правил БУ, который брал за основу IFRS (в основном его) или GAAP и подгонял под местные традиции учета и законы (Налоговый кодекс, Закон о налогооблажении прибыли и т.д.)
Их, кстати, можно глянуть из локализаций для разных стран по той же АХ https://docs.microsoft.com/en-us/dyn...ic-information

[mazzy]

Цитата:

Сообщение от Lemming

Кстати, ещё одна интересная деталь заключается в том, что в открытом доступе практически нет информации по бухгалтерскому учету, причем не только Российскому, но вообще по всему миру. Кроме того, всё что касается ERP так же почти не представлено в интернете, исключение наверное составляют около-технические темы по SAP, Dynamics и Odoo. Даже по 1С практически нет ресурсов, которые бы что-то рассказывали для других профессионалов.

Эта информация обычно идет по подписке.
По 1С - ИТС. Не знаю как сейчас называется.

Повелось с давних пор 90-2000х. У САПа еще раньше.
Тогда каналы распространения были слабые, на физических носителях.
А сейчас привыкли. Зачем выкладывать в открытый.

Цитата:

Сообщение от Lemming

Однако, бухгалтерский и налоговый учет в разных странах отличается.

на самом деле - не очень то учёты и отличаются.
везде законодатели стремятся выжать из бизнеса что могут. везде есть:
* фиксированные (вмененные) налоги,
* налоги с оборота,
* налоги с прибыли.
* в большинстве стран есть налоги на использование (в России это транспортный налог).
различаются коэффициенты и количество ступеней с этими коэффициентами.

кроме того, налоги могут считать как по обороту за период, по документу в целом (налог на общую сумму документа), так и на строки документа.

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

другими словами, если в системе будут унифицированные алгоритм расчета затрат и вознаграждений, то различные учёты вполне реализуются.

тут дело не в этом.
тут важно к чему люди привыкли - "привычки" и "удобства".

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

например, в то же дании похоже привыкли вводить "многострочные проводки". они отлично понимают концепцию корр.счета. но считают однострочные проводки неудобными (и в этом есть рациональное зерно).

а вот в странах СНГ с трудом отказыаются от однострочных проводок (и в этом тоже есть рациональное зерно).
нужно чтобы "как в 1С".

===========
в тех же штатах функционал по работе с валютами считают избыточным. странно, правда?

а вот в европе, наоборот, учетную систему без валют считают неполноценной.

===========
отдельно стоят всякие "удобства".

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

но некоторые люди привыкли работать с деревом и считают фильтры неудобными и усложняющими.
а некоторые совершенно не представляют как это система не позволяет наложить фильтры по произвольным полям в произвольном порядке.

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

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

это не учёт. это доп.функции к учету. именно эти функции отличаются в разных странах. именно они делают ту или иную систему привлекательной для клиентов.

==================
взять ту же белорусскую lsFusion
https://github.com/lsfusion-solutions/erp
https://documentation.lsfusion.org/d...US/Online+demo
уж как они хотят сделать универсальную хотя бы для стран СНГ. Но и то постоянно проскальзывает что-то белорусское, что для них является естественным и безальтернативным, а меня, например, в ступор вводит как "малако".

и это не учёт

==================
и да! как же я забыл - изменение проведенных документов (перепроведение и отмена проведения).

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

в некоторых странах (не только СНГ, но и в азиатских, и в испаноязычных) изменение проведенных документов считается вполне допустимой и обыденной практикой. система без системы перепроведения будет считаться чертовски неудобной.

[gl00mie]

Цитата:

Сообщение от mazzy

на самом деле - не очень то учёты и отличаются. везде законодатели стремятся выжать из бизнеса что могут. если в системе будут унифицированные алгоритм расчета затрат и вознаграждений, то различные учёты вполне реализуются.
===========
отдельно стоят всякие "удобства".
например, в России система без реализованного клиент-банка хотя бы со Сбербанком будет считаться неполноценной.
например, система без выгрузки в налоговую также будет считаться неполноценной.
это не учёт. это доп.функции к учету. именно эти функции отличаются в разных странах. именно они делают ту или иную систему привлекательной для клиентов.
==================
и это не учёт

Я бы взглянул на тему чуть под другим углом. Если рассматривать систему не как что-то, реализующее отдельно "учет" и отдельно "удобства", а как нечто, реализующее различные end-to-end сценарии использования, то многие вещи станут на свои места. Скажем, зачем типичному российскому буху система, которая может составить платежный календарь, но не может отправить платёжки и получить банковскую выписку через DirectBank (или условно интегрироваться со Сбером, как писали выше)? Зачем буху система, которая может посчитать налоги, но не может отправить электронную налоговую декларацию в Налоговую? И да, сценарии использования в разных странах отличаются, поэтому и требования к функционалу учетной системы такие разные: в штатах - поддержка печати бумажных чеков, формата NACHA для электронных переводов и формы 1099, в ЕС - переводов SEPA Credit Transfer, "подписочных" снятий SEPA Direct Debit, во Франции - выгрузка файла аудита FEC, etc. Но суть одна: чем больше сценариев использования "от и до" поддерживает система для того или иного рынка, тем интереснее она.

[EVGL]

А теперь - по существу:

• США: поддержка печати бумажных чеков, электронный формат Positive pay для их проверки, для электронных переводов формат NACHA, для платежей поставщикам - физическим лицам нужна поддержка формы 1099.
• ЕС в общем: поддержка переводов SEPA Credit Transfer, поддержка "подписочных" снятий SEPA Direct Debit (в каждой стране могут быть легкие отклонения от формата, во Франции - указание номера предприятия SIRET). Отчет EU Sales list при поставке услуг (у всех - строго свой). Поддержка INTRASTAT при торговле товарами. См. сюда: https://erconsult.eu/blog/minimalist...ation-in-d365/ Ежемесячный отчет по НДС (у каждой страны - свой).
• Франция: выгрузка файла аудита FEC. Возможность взимать НДС по оплате или по счету по выбору в каждом конкретном случае.
• Германия: выгрузка файла аудита GoBD. Подготовка баланса eBilanz в формате XBRL.

Сам бухучет не отличается. Есть дебет и кредит. В конце года подводим итоги и закрываем прибыль на капитал

[mazzy]

Цитата:

Сообщение от EVGL

А теперь - по существу:

"И это не учёт", это те самые удобства.
Бггг.

====================
я вот тут подумал, что стоит добавить еще один паттерн, общий для всех erp.

как бы ни ограничивали перепроведение, но везде есть паттерн:
1. делаем первичку
2. на основании первички создаем "налоговый" учет, который допускает ручные коррекции
3. на основании "налогового" учета делаем отчеты, выгрузки и т.п.

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

В проклято-буржуинии всякие налоги на использование (UseTax, в стандартной Аксапте разными людьми реализовано раз 5-6), разные Intrastat, тот же XBRL

В Аксапте конечно же стоит вспомнить Layer::Operational, Layer::Tax в LedgerTrans... наши локализаторы не заметили этих слоев, поскольку искренне считали, что двойного учёта на холме быть не может Наши люди искрене считали, что такой паттерн "налоги считать на основании скорректированных врунчую проводок" применяется исключительно в России. Поэтому сделали в Аксапте отдельный налоговый учет и отдельные книги продаж и покупок

А такой паттерн есть везде.

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

то движок можно считать сделанным в бета-версии

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

в том числе, о чём так блестяще сказал EVGL

[EVGL]

Цитата:

Сообщение от mazzy

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

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

В связи с этим, малые и средние, не публичные компании редко переоценивают основные средства по нескольким моделям. Хватает налоговой.

[Logger]

Цитата:

Сообщение от EVGL

Сам бухучет не отличается. Есть дебет и кредит.

Корреспонденция счетов еще сильно влияет.

[EVGL]

Цитата:

Сообщение от Logger

Корреспонденция счетов еще сильно влияет.

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

[Logger]

Цитата:

Сообщение от EVGL

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

Чо-то вас не туда понесло батенька.

[EVGL]

Цитата:

Сообщение от Logger

Чо-то вас не туда понесло батенька.

Люди путают корреспонденцию счетов в плане правил и условностей ведения бухучета (манифестируется в русской "шахматке", пример: не разноси предоплату от клиента в корреспонденции со счетом доходов, не списывай сразу исходящий платеж, если он идет несколько дней и тебе / твоему аудитору это важно) и одноименную двойную запись с попарным дебетом и кредитом (экс-СССР). Так что вы поясните, что имеется в виду.

[EVGL]

Если же говорить о детализации проводок и плана счетов, то принцип везде один, но:

должен быть определенный уровень детализации, иначе трудно готовить баланс и декларацию по налогу на прибыль, декларацию по НДС:
ЕС: надо разделять счета оборота с продажи "дома", в других странах ЕС, за пределами ЕС, чтобы условно говоря база каждого вида исходящего НДС была отдельно на своем счете.
Во Франции надо использовать французский план счетов, а в остальных означенных странах - какой угодно.

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

Больше всего заморочек с командировочными расходами:
https://erconsult.eu/blog/configurin...diems-in-d365/

[mazzy]

Цитата:

Сообщение от EVGL

Надо разделять счета амортизации по виду основных средств

Да, кстати про амортизацию, спасибо что напомнил!

амортизация - это отрицательные налоги.

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

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

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

[axm2017]

Цитата:

Сообщение от Lemming

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

Логично не лезть в то что не понимаешь так как риск зарыться.

Микрософт для 365- ки по большому счету поменяла просто часть движка не трогая код. Никто не мешает вам пойти тем же путем

[AlGol]

Цитата:

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

Раньше, в доисторические времена, просто приходили в книжный магазин и покупали книжку типа "Документооборот в бухгалтерском учете" или "Порядок оформления типовых хозяйственных операций в бухгалтерском учете".
Это, в приципе, считалось открытым доступом.
А что у нас сейчас? Да пожалуйста:
https://www.ozon.ru/product/buhgalte...anie-224850132

[EVGL]

Точно. А на столе как венского студента, так и седого бухгалтера-энтузиаста лежит стандартный труд https://www.thalia.at/shop/home/arti...E&gclsrc=aw.ds

[Logger]

Ого, вот это список!

Интересно, а на Украине как ?

[cuba]

Цитата:

Сообщение от Logger

Ого, вот это список!

Интересно, а на Украине как ?

В Украине однострочная проводка

[Logger]

Интересно, кстати, а как принято в Китае и Индии.
Индийские налоги кстати вроде наши локализаторы делали.
Может есть кто в теме.

[mazzy]

Цитата:

Сообщение от Logger

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

как скажешь.
я комментировал твою фразу:

Цитата:

Сообщение от Logger

А по поводу промежуточных счетов через которые все приходится прогонять...
Ну и что ? Это же обычно дело. В бухучете это сплошь и рядом. Загнали на счет, накопили, потом списали.

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