Если бы вы создавали 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") и проведенный документ (влияет на итоги). переход в статус "проведенный документ" может сопровождаться проверками разными исполнителями. иногда такие проверки являются обязательными. система, допускающая перепроведение будет считаться маргинальной.

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

[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.

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

[EVGL]

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

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

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

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

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

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

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

[EVGL]

Цитата:

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

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

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

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

[Logger]

Цитата:

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

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

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

[EVGL]

Цитата:

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

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

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

[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]

Цитата:

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

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

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

[EVGL]

Цитата:

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

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

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

[Logger]

Цитата:

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

Так что вы поясните, что имеется в виду.

Корреспонденция счетов подразумевается в любой учетной системе для бухучета.
Я имел в виду то что в аксапте под этим имеют в виду в том виде как это переведено на русский.

Т.е. делаем ли мы сразу простые проводки с однозначным дебет кредитом как в 1С или делаем сложные многострочные проводки, которые потом героически превращаем где то внутри в однострочные.

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

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


P.S.
А вообще я думаю что TC затеял безнадежное дело. Серьезные системы не пишутся силами одного разработчика. По итогу будет потерянное время и разочарование.

Плюс, я думаю что программисту очень трудно нормально спроектировать удачную ERP-систему (не конкретно Lemming - у) а вообще абстрактному супер пупер программисту. Его неизбежно затянут технологические детали, понравившиеся фичи и.т.п. Нужно быть аналитиком с хорошим опытом внедрения основных модулей и неким опытом разработки тоже. Опыт внедрения не даст оторваться от реальности. Даст понимание что реально нужно заказчику а на что даже не стоит смотреть не то что тратить какой-то ресурс. Это очень важно. Иногда смотришь на целые мертворожденные куски в аксапте и грустишь на что был потрачен ресурс. Во времена дамгаардов такой фигни не было.

[EVGL]

Цитата:

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

Т.е. делаем ли мы сразу простые проводки с однозначным дебет кредитом как в 1С или делаем сложные многострочные проводки, которые потом героически превращаем где то внутри в однострочные.

3 проводки объективно проще, чем 4, так что это с вашей стороны обусловленная практиками конкретной страны предвзятость. Клиент не платит отдельно 20 рублей НДС и отдельно 100 рублей в ваш карман, он платит 120, а делить уже вам. Эта тема обсуждалась недавно.

В ряде случаев для внутреннего анализа на предприятии интересно иметь, конечно, 100 отдельно. В моей практике это налог в "фонд поддержки семьи" с выплат собственнику / директору предприятия, который сам по себе может быть предпринимателем и получать доход естественно в итоге за вычетом НДС, т.е. платеж платежу рознь. Но это экзотика.

[Logger]

Цитата:

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

3 проводки объективно проще, чем 4, так что это с вашей стороны обусловленная практиками конкретной страны предвзятость. Клиент не платит отдельно 20 рублей НДС и отдельно 100 рублей в ваш карман, он платит 120, а делить уже вам. Эта тема обсуждалась недавно.

Возможно я пропустил это обсуждение.

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

Пользователю потом можно как хочешь показать, сгруппировать по документу / ваучеру и показать как одну сложную проводку по документу.
Если пользователь рукам вводит, то думаю что можно что-то придумать по превращению в однострочные сразу при записи.

3 проводки может и проще чем 4 но пока вы на них смотрите глазами. А если строите всякие хитрые отчеты иди задаетесь другими вопросами, то 4 будут проще и однозначнее.

По поводу клиента - он платит 120, но при этом всегда есть информация сколько там НДС. И это жеж неспроста. Ну а мы отражаем в учете как нам надо.

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

[EVGL]

Цитата:

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

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

Нет, в точности наоборот, поскольку соответствие Ledger - Subledger превращается из 1:1 в N:1. Где тут удобство?

Цитата:

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

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

[Logger]

Цитата:

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

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

А где вам доводилось внедрять кроме Швейцарии и Австрии ?
Везде многострочные используются ?

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