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

[EVGL]

Цитата:

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

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

В Германии, Польше, Чехии, Венгрии, Франции, Великобритании, США, Испании, Италии, Швеции, Норвегии, Дании, Таиланде и теперь Бразилии. Везде используются многострочные.

[Logger]

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

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

[mazzy]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[cuba]

Цитата:

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

[Logger]

Цитата:

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

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

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

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

Но ведь можно сделать как сейчас получается в аксапте после применения корреспонденции счетов.
Одна полупроводка со счетом и признаком сторно, суммой и аналитикой.
+ связанная с ней полупроводка (запись в той же табличке).

Тогда все возражения снимаются.

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

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

[mazzy]

Цитата:

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

а тут ответ очевиден.

Цитата:

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

(кстати, раз уж заводить 2 счета в строке то почему не две аналитики?).

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

Цитата:

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

Но ведь можно сделать как сейчас получается в аксапте после применения корреспонденции счетов.

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

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

Цитата:

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

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

откуда взялось слово "Одна"?
и почему связанная тоже одна?

много полупроводок с дебетом И много полупроводок с кредитом.

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

Цитата:

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

Тогда все возражения снимаются.

нет

Цитата:

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

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

Да, в бухучете, который основан на корреспонденции, "это сплошь и рядом".

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

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

[Logger]

Цитата:

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

Да, в бухучете, который основан на корреспонденции, "это сплошь и рядом".

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

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

Погоди, так о чем спор-то ?

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

[Logger]

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

[BOAL]

Цитата:

Даже по 1С практически нет ресурсов, которые бы что-то рассказывали для других профессионалов.

См. сайт https://1c-dn.com/
международный 1С
Инфа по платформе и ERP WE
https://1c-dn.com/solutions/1c-erp-world-edition/
Для рус. спецов есть куча инфы, но внутри ИТС 1Са, во вне же ИТС торчит очень слабо, нужно авторизация

[mazzy]

также русскоязычный https://wonderland.v8.1c.ru/

[mazzy]

Цитата:

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

См. сайт https://1c-dn.com/
международный 1С

там есть trial версии! вот ведь что конкуренция животворящая делает.

до сих пор знал, что есть демо версии https://demo.1c.ru/. Но это только веб-клиент.

[gl00mie]

Цитата:

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

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

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