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

[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

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

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

[Logger]

Цитата:

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

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

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

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

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

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


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

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

[EVGL]

Цитата:

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

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

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

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

[mazzy]

Цитата:

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

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

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

систему с корреспонденцией придумали немцы перед второй мировой войной.
и передали в Союз в рамках обмена опытом.

Цитата:

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

Я имел в виду то что в аксапте под этим имеют в виду в том виде как это переведено на русский.

Да, согласен с EVGL, очень многие путают.

Цитата:

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

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

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

как только пытаешься добавить аналитику, так сразу возникает вопрос - к дебету или к кредиту относится аналитика.

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

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

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

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

============================
чуть сложнее: получили от поставщика товары с НДС, поставщик дал скидку.
Дт Товар1 60
Дт Товар2 40
Дт НДС 20
Кт Поставщик 115
Кт Скидка 5

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

вопрос на размышление, если инвойс поставщика был в Евро, скидка в Долларах, а товар на складе учитываем в рублях,
то однострочные проводки точно проще?

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

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

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

[mazzy]

Цитата:

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

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

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

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