andreymxНи разу с ERP еще не работал (пока).

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

вообще все такие вещи делаются по другому

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

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

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

;)))))))))))))

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

Александр ПузаковЕсть целое ПБУ 22/2010, которым регламентировано исправление ошибок, которое не допускает подобных свистоплясок в принципе. А малограмотных бухгалтеров надо по рукам бить.
к сожалению, не все зависит от квалификации бухгалтера. не забывайте, в какой стране все происходит )))

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

iscrafmуточните плз о чем речь. Какие инструкции противоречат законам и какие есть "дурацкие ограничения"?
пример:
http://chp.com.ua/forums/lofiversion/index.php/t14102.html
очень хорошо показывает, о чем постоянно приходится думать бухгалтеру.

при желании можно найти десятки (если не сотни) таких примеров.

или вот еще:
"Враховуючи викладене, у випадку постачання послуг, що вимірюються лише у вартісному виразі, в розділі І податкової накладної: у графі 3 –необхідно вказати номенклатуру постачання послуг; у графі 5 – проставити "грн..", у графі 6 - зазначити " послуги "."

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

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

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

iscrafmэто просто правило оформления документа, не более. Оформляющий этот документ конечно должен их знать, на крайний случай распечатать и держать под рукой. Или воспользоваться программой которая в состоянии корректно оформить данный документ. Ничего необычного.
так а я и не говорю, что это что-то супер сложное.
тут весь прикол в том, где взять правила, по которым налоговики через N месяцев будут проверять корректность твоей первички. фраза "почитать нормативные акты" не подходит - там про многие вещи вообще ничего не написано, или разъяснение налоговой говорит одно, закон другое, инструкция минфина третье, а решения судов - четвертое ))))))
и все эти органы регулярно меняют свое мнение )))))))
http://www.buhoblik.org.ua/nalogi/nds/616-nalogovaya-nakladnaya-2013-ukraina.html

если думаешь, что я сгущаю краски - можем сыграть в квест - найти нормативный акт, в котором подробно описывается "Как в Украине надо будет правильно заполнять НН с указанием номера и даты ГТД импортированных товаров"
например - какую ГТД указывать, если товар пришел несколькими партиями по разным ГТД - по ФИФО, ЛИФО, или как-либо еще? вести этот расчет по фирме в целом, или в разрезе складов (филиалов)? а что делать, если были возвраты от клиентов? и т.д.

"Закон № 5503 (п.34 раздела I) перенес на 01 июля 2013 года дату начала указания в налоговой накладной даты и номера грузовой таможенной декларации, по которой былo осуществлено таможенное оформление импортного товара (см. пункт 30, которым дополнен подраздел 2 раздела XX НКУ)."

то есть до дня Д осталось полтора месяца, и вообще-то надо начинать готовиться...

Ivan DurakВ нормальных системах есть 2 даты. Дата операции и дата заведения в систему этой операции.
После чего состряпать отчет по состоянию на любую дату - как 2 пальца
в нормальных системах есть МНОГО дат
1 дата документа (дата, напечатанная на бумажке)
2 дата, которой должен быть учтен документ
3 дата создания документа (когда занесен в систему)
4 дата последней модификации документа (когда менялись данные)
5 дата, когда нажали на кнопку учет

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

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

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

формируем 13.05.2013 отчет об остатках на складах на дату 01.05.2013, и при этом желаем видеть в отчете цифры, которые мы видели 06.05.2013 при формировании отчета об остатках на складах на дату 01.05.2013 (06.05.2013 документа в системе не было)
расскажи всем, как ты такой отчет будешь строить


заметь, я не говорю, что это невозможно. мне просто хочется послушать о Ivan Durakкак 2 пальца применительно к этому отчету.

Old Nick
2. Дата, которой должен быть учтен документ - Операция "Проведение документа по регистру План"

5. Дата, когда нажали на кнопку учет - Операция "Проведение документа по регистру Факт"


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

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

к плану ни одна из этих дат не имеет отношения

Old Nick1. Дата печати документа - Операция "Печать"

опять же, не надо путать операции и реквизиты документа.
документ вполне мог быть выписан вручную, и только через некоторое время занесен в базу (я именно это предполагал в примере)
так что есть просто реквизит "Дата Документа", он же дата хозяйственной операции - и эта дата не имеет никакого отношения к операциям
можно хранить дату, когда документ распечатан последний или первый раз или вообще список, кто и когда печатал документ - но это абсолютно разные вещи
Old Nick3. Дата создания документа - Операция "Создание документа"
4. Дата модификации документа - Операция "Редактирование документа"

да, эти даты можно связать с определенными операциями в системе.

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

Old Nicks_ustinov,

Это всё равно два разных регистра, пусть не план и факт, а что-то другое.

да ну? ))))))))))
вы вообще понимаете смысл даты, напечатанной на документе?

дата, когда бухгалтер фактически выполнил учет - это просто справочное поле )))

Old NickЯ то как раз понимаю, потому что именно на учетных системах специализируюсь. И у меня ваших проблем не существует.
У меня тоже проблем не существует, так как не пытаюсь строить любые отчеты )

но все же, озвучьте - что, по вашему мнению, означает дата, напечатанная на документе?

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

В документе чаще всего дата регистрации в журнале. И чаще всего одновременно с регистрацией происходит создание проводок

..........

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

Таблица операций
1. Создание документа Петров 10.02.12
2. Регистрация документа Петров 10.02.12
3. Формирование проводок Петров 10.02.12
4. Перепроведение проводок Петров 12.02.12 (с датой 10.02.12)

Журнал документов
1. Одна дата 10.02.12

Журнал проводок
1. Одна дата 10.02.12

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

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

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

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

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

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

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

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

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

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

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

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

при работе с отчетами иногда нужна "стабильность" данных. то есть можно пренебречь некоторыми неточностями (проведены не все документы, которые должны), но данные не должны меняться

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

Old NickЕще раз отвечу, нет даты документа, есть дата регистрации документа. Если ваша система позволяет выполнить проводку без документа, то это клиника...

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

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

s_ustinovдокумент - продажа (сведем к 2 датам, как ты написал)
дата документа и дата, которой должен быть учтен документ 20.04.2013
дата создания, последней модификации и нажатия на кнопку учет 10.05.2013

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

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

формируем 13.05.2013 отчет об остатках на складах на дату 01.05.2013, и при этом желаем видеть в отчете цифры, которые мы видели 06.05.2013 при формировании отчета об остатках на складах на дату 01.05.2013 (06.05.2013 документа в системе не было)
расскажи всем, как ты такой отчет будешь строить
Old NickУчитесь правильно проектировать, тогда и будет как 2 пальца
s_ustinovвпрочем, я с удовольствием послушаю, как у вас, в правильно спроектированной системе, решается та задача, которую я привел - отчет по остаткам на конец месяца (количество и стоимость по фифо)
так мы услышим рассказ о супер возможностях "правильно спроектированной программы"?

Old Nick,
воспользуюсь своим же советом, и опишу задачу так, как это могут описать пользователи.

Есть правильно спроектированная программа, в которой ведется учет

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

Бухгалтер вносит эту продажу в программу (на экране справа внизу дата - 10.05.2013), нажимает некие кнопки - и программа начинает все отчеты показывать так, как будто эту продажу ввели в программу 20.04.2013. (Ругаемая некоторыми 1С делает это легко и непринужденно, за что ее и любят бухгалтера). Предположим, что остатков хватает и в минус ничего не ушло - ведь этот товар действительно физически отдали клиенту - то есть он был на складе в нужном количестве. Разумеется, я не утверждаю, что бухгалтер работает в 1С - бухгалтер работает в "правильно спроектированной программе", которая для данной ситуации предоставляет те же возможности, как и 1С. И наличие такого функционала - не прихоть бухгалтера, а необходимость - иначе будут проблемы с проверяющими госорганами.

13.05.2013 директор проводит очередное совещание (продажи, скорость оборота и тп). И с негодованием замечает, что на прошлом совещании (06.05.2013) в некоторых отчетах были другие цифры. Он вызывает к себе правильного проектировщика и говорит:
ты ведь правильно спроектировал программу? и отчеты любые тебе сделать - как 2 пальца? так сделай мне так, чтобы я видел все отчеты такими, какими я их видел 06.05.2013, а бухгалтер видел такими, какие они должны быть после всех его корректировок.
Например, один из необходимых отчетов - остатки по складам с количеством и суммой по каждому товару по состоянию на 01.05.2013.

Внимание, вопрос - как именно правильный проектировщик в правильно спроектированной программе будет реализовывать "как 2 пальца" такое пожелание директора?