|
![]() |
#1 |
Участник
|
|
|
![]() |
#2 |
Banned
|
Люди путают корреспонденцию счетов в плане правил и условностей ведения бухучета (манифестируется в русской "шахматке", пример: не разноси предоплату от клиента в корреспонденции со счетом доходов, не списывай сразу исходящий платеж, если он идет несколько дней и тебе / твоему аудитору это важно) и одноименную двойную запись с попарным дебетом и кредитом (экс-СССР). Так что вы поясните, что имеется в виду.
|
|
![]() |
#3 |
Участник
|
Корреспонденция счетов подразумевается в любой учетной системе для бухучета.
Я имел в виду то что в аксапте под этим имеют в виду в том виде как это переведено на русский. Т.е. делаем ли мы сразу простые проводки с однозначным дебет кредитом как в 1С или делаем сложные многострочные проводки, которые потом героически превращаем где то внутри в однострочные. Я думаю, что если делать универсальный движок, то лучше сразу простые проводки делать. Эта запись содержит больше информации и если пользователю захочется, то легко представима в виде сложной проводки просто за счет группировки. А наоборот будет гемор как с корреспонденцией в аксапте. Сложная, ресурсоемкая и неоднозначная процедура. P.S. А вообще я думаю что TC затеял безнадежное дело. Серьезные системы не пишутся силами одного разработчика. По итогу будет потерянное время и разочарование. Плюс, я думаю что программисту очень трудно нормально спроектировать удачную ERP-систему (не конкретно Lemming - у) а вообще абстрактному супер пупер программисту. Его неизбежно затянут технологические детали, понравившиеся фичи и.т.п. Нужно быть аналитиком с хорошим опытом внедрения основных модулей и неким опытом разработки тоже. Опыт внедрения не даст оторваться от реальности. Даст понимание что реально нужно заказчику а на что даже не стоит смотреть не то что тратить какой-то ресурс. Это очень важно. Иногда смотришь на целые мертворожденные куски в аксапте и грустишь на что был потрачен ресурс. Во времена дамгаардов такой фигни не было. |
|
|
За это сообщение автора поблагодарили: Lemming (5). |
![]() |
#4 |
Banned
|
Цитата:
В ряде случаев для внутреннего анализа на предприятии интересно иметь, конечно, 100 отдельно. В моей практике это налог в "фонд поддержки семьи" с выплат собственнику / директору предприятия, который сам по себе может быть предпринимателем и получать доход естественно в итоге за вычетом НДС, т.е. платеж платежу рознь. Но это экзотика. |
|
![]() |
#5 |
Участник
|
Цитата:
Если проводки формируются автоматически из кода, то удобнее их делать как однострочные. По итогу меньше проблем получается. (В аксапте кстати везде торчит код локализации с расстановкой скобок корреспонденции, что, по сути, является хинтом для движка по превращению многострочных проводок в однострочные) Пользователю потом можно как хочешь показать, сгруппировать по документу / ваучеру и показать как одну сложную проводку по документу. Если пользователь рукам вводит, то думаю что можно что-то придумать по превращению в однострочные сразу при записи. 3 проводки может и проще чем 4 но пока вы на них смотрите глазами. А если строите всякие хитрые отчеты иди задаетесь другими вопросами, то 4 будут проще и однозначнее. По поводу клиента - он платит 120, но при этом всегда есть информация сколько там НДС. И это жеж неспроста. Ну а мы отражаем в учете как нам надо. Кстати с учетом вашего опыта внедрений аксапты в европе, где-нибудь встречалась такая схема как в России, чтобы использовались однострочные простые проводки ? Я думаю, что должны быть. |
|
![]() |
#6 |
Banned
|
Цитата:
Цитата:
Кстати с учетом вашего опыта внедрений аксапты в европе, где-нибудь встречалась такая схема как в России, чтобы использовались однострочные простые проводки ? Я думаю, что должны быть.
|
|
![]() |
#7 |
Участник
|
Цитата:
Везде многострочные используются ? Автор темы запрашивает как построить универсальную архитектуру. Логично запроектировать так, чтобы в движке любой способ было легко поддерживать. Я исхожу из этого. Однострочные проводки группировкой по номеру документа легко превращаются в многострочные. Обратное неверно. |
|
![]() |
#8 |
Участник
|
Цитата:
в любой учетной системе подразумевается двойная запись (сумма дебетов = сумме кредитов) а вот корреспонденция есть мало где. систему с корреспонденцией придумали немцы перед второй мировой войной. и передали в Союз в рамках обмена опытом. Цитата:
Цитата:
как только пытаешься добавить аналитику, так сразу возникает вопрос - к дебету или к кредиту относится аналитика. например, валюта. обрати внимание, что в одной однострочной проводке невозможно отобразить ситуацию реальной жизни, когда дебет одной валюты, а кредит в другой. ![]() придется делать несколько однострочных проводок, придумывать какие-то промежуточные счета (EVGL говорил как раз об этом) количество... в производстве нельзя отобразить расход материалов в количестве M, а приход готовой продукции в количестве N. снова через промежуточные счета а вот в многострочной проводке - тривиально. поскольку двойная запись ограничвает только суммы ![]() в современных учетных системах аналитических признаков много. и значения этих признаков могут быть разными для дебетов и кредитов. ============================ чуть сложнее: получили от поставщика товары с НДС, поставщик дал скидку. Дт Товар1 60 Дт Товар2 40 Дт НДС 20 Кт Поставщик 115 Кт Скидка 5 чтобы отобразить такую операцию, однострочных проводок нужно много. а главное, нужно решать вопросы, никакого отношения к реальной жизни не имеющие - на какой товар отнести скидку? а может увеличить оборот с поставщиком? а если от оборота считаются рибейты? и т.п. вопрос на размышление, если инвойс поставщика был в Евро, скидка в Долларах, а товар на складе учитываем в рублях, то однострочные проводки точно проще? ================== поэтому учетным системам как раз гораздо проще набрасывать движения отдельными строками. каждый модуль делает свое движение, со своими признаками. и лишь в самом конце, перед финализацией(разноской) проверяется требование двойной записи - сумма дебетов в основной валюте должна быть равна сумме кредитов в основной валюте. кроме того, в конце можно проверить и другие условия, сгруппировать однотипные проводки, расставить корреспонденцию и т.п. Последний раз редактировалось mazzy; 30.06.2021 в 14:28. |
|
|
За это сообщение автора поблагодарили: EVGL (5). |
![]() |
#9 |
Участник
|
Цитата:
даже суммирование по многострочным проводкам проще - фильтр по одному полю и сумма по другому полю - тривиальнейший select запрос. а вот суммирование по однострочным сложныее - либо надо делать два запроса и вычитать результат, либо хитро выкручиваться с функциями в списке полей ![]() |
|
![]() |
#10 |
Участник
|
Цитата:
Сообщение от mazzy
![]() как раз наоборот.
даже суммирование по многострочным проводкам проще - фильтр по одному полю и сумма по другому полю - тривиальнейший select запрос. а вот суммирование по однострочным сложныее - либо надо делать два запроса и вычитать результат, либо хитро выкручиваться с функциями в списке полей ![]() Вероятно ты полагаешь что однострочную проводку я предполагаю делать как запись в одной табличке в которой есть поле дебет, поле кредит, поле сумма, поле аналитика непонятно к чему (дебету или кредиту) относящаяся (кстати, раз уж заводить 2 счета в строке то почему не две аналитики?). Но ведь можно сделать как сейчас получается в аксапте после применения корреспонденции счетов. Одна полупроводка со счетом и признаком сторно, суммой и аналитикой. + связанная с ней полупроводка (запись в той же табличке). Тогда все возражения снимаются. Аналитика по каждому счету. Фильтрация по одному полю итп. Есть плюсы многострочных проводок как ты их выше описал. Есть плюсы однострочных проводок. Есть один минус для выражения условия типа "взять оборот по счету такому то в корреспонденции со счетом таким" то может потребоваться делать джоин. Ну, серебряной пули не бывает. А по поводу промежуточных счетов через которые все приходится прогонять... Ну и что ? Это же обычно дело. В бухучете это сплошь и рядом. Загнали на счет, накопили, потом списали. Последний раз редактировалось Logger; 30.06.2021 в 14:34. |
|
![]() |
#11 |
Участник
|
![]() как я уже говорил, аналитик может быть много. кроме того, каждый кусок кода в каждом модуле должен знать - дебет ему заполнять или кредит Цитата:
но не все движения можно откорреспондировать в общем случае (пример операции с приходом я привел выше. обязательно подумай о случае с разными валютами) конечно, для корреспонденции можно принудительно разделить полупроводки. чтобы принудительно разделить, нужно знать смысл операции, нужны некие эвристики. (аксапта сейчас так и делает) а это уже не универсальный движок ![]() например, сейчас аксапта не корреспондирует многие проводки, созданные модулем Проекты. ![]() Цитата:
и почему связанная тоже одна? много полупроводок с дебетом И много полупроводок с кредитом. кстати, в буржуйской аксапте то, что ты называешь "полупроводкой" называются "движением по счету" ![]() дело в том, что движение - это НЕ "полу..." нет ![]() Цитата:
А в проклятобуржуинских гаапах и иасах накопительно-котловые счета считаются "повышающими подозрение на махинации" при аудите (я не помню этого термина точно) в общем, накопительные счета не рекомендуются в западных учетах. случаи типа незавершенного производства, закрытия года, распределения бонусов и т.п. оговариваются там отдельно. Последний раз редактировалось mazzy; 30.06.2021 в 15:06. |
|
![]() |
#12 |
Участник
|
Цитата:
Сообщение от mazzy
![]() ![]() Да, в бухучете, который основан на корреспонденции, "это сплошь и рядом". А в проклятобуржуинских гаапах и иасах накопительно-котловые счета считаются "повышающими подозрение на махинации" при аудите (я не помню этого термина точно) в общем, накопительные счета не рекомендуются в западных учетах. случаи типа незавершенного производства, закрытия года, распределения бонусов и т.п. оговариваются там отдельно. Изначально речь шла о том как сделать универсальную штуку которой можно удобно отразить разные требования. Незаметно ты соскочил на обсуждение как правильно и что лучше. Это совсем другая тема. И весьма спорная, кстати. |
|
Теги |
open source erp |
|
![]() |
||||
Тема | Ответов | |||
Если бы я писал ERP-систему | 23 | |||
ERP-системы — мэйнстрим или тупиковая ветвь? | 30 | |||
О причинах неудачных внедрений ERP | 4 |
|