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

[EVGL]

Цитата:

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

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

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

[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. Где тут удобство?

Цитата:

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

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

[mazzy]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

[Logger]

Цитата:

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

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

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

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

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

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

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

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

[mazzy]

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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

Цитата:

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

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

нет

Цитата:

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

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

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

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

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