Manag, я-то имел ввиду под "налоговым учетом" коллег, которые внедряют этот самый налоговый учет. Для них эта дата документа особенно важна...
А по поводу очковтирательства: в российской учетной практике принято документы относящиеся к прошлым периодам оформлять "задним числом". Близкий всем нам пример. Консалтинговая компания оказывала услуги клиенту в августе. Пока подписали все ТШ, пока все свели в кучку, в итоге акт реально появляется числа 3-5 следующего месяца. Но, как правило, на нем указывают дату 31-авг. Это удобно всем сторонам - доходы у одних и расходы у других отражаются в августе. То же самое работает и для договоров коль скоро у нас для государства и судов легитимна только бумага: физически печати и подписи на документах появляются много позже, хотя все решения приняты и для непосредственных участников они легитимны.

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

Вот ведь, все аргументы привели в мою пользу, а вывод почему то другой. Для того в системе и сделана дата документа, чтобы она могла отличаться от даты проводки и даты ввода документа. Когда вы работали в "самопальной" системе, там разработчики, как правило, о таких "мелочах" не задумываются. Хорошо, если предусмотрят возможность провести документ датой отличной от даты ввода. Здесь же есть дата документа и вы не знаете что с ней делать. "Ну так пусть она тогда равняется дате проводки", - говорите вы. Нет, это неправильно.
Если вы хотите, чтобы выручка прошла в августе, а документ подписан 20 сентября. Поставьте дату проводки=дата оказания услуг (например, 20 августа), а дату документа 20 сентября. Ввести вы его можете 25 сентября - это будет дата создания. Ну а если документ создается и подтверждается непосредственно в системе без бумажного оригинала, то дата документа = дата его подтверждения в системе. Дату проводки ставьте какую нужно. И это действительно удобно всем. Весь мир так работает. А мы привыкли "исправлять" отчетность и иногда самих себя обманываем. В конце концов, если вы хотите распечатывать первичные документы, в которых нет даты документа, а есть просто дата, которая = дате проводки, никто не мешает вам такую выходную форму сделать. Только не надо менять семантический смысл полей базы данных, предусмотренных разработчиками системы, только из-за того, что некоторые российские бухгалтеры до сих пор считают советскую систему бух. учета самой правильной. Это будет лишнее препятствие для выхода на мировые рынки и международной интеграции. Хотя, конечно, и не самое сложное препятствие.

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

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

Я же исхожу из того, что любое повышение энтропии в системе должно иметь какую-то реальную цель. Даже только за тем, чтобы не запутаться. Так вот в этом случае замечательное поле дата документа будет отличаться от даты проводки "только по делу".
Например, компания САП СНГ в своем решении по налогу на прибыль предложила такую концепцию для даты документа: дата документа заполняется датой, в которой в соотвествии с положениями НК РФ были произведены доходы или расходы. Все. Если даты признания в БУ и НУ совпадают, тогда оба поля заполнены одинакого. Эта реально работающая концепция, позволяющая организовать два учета. В ее рамках вполне неплохо бы и расчет заказов проводить с датой документа равной дате проводки.

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

а давайте теперь про дату валютирования поговорим

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

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

это так и должно быть?

опишу более конкретно проблему.

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

это можно как-то победить? а то фактическая себестоимость в валюте концерна считается по какому-то непонятному курсу.