В Беларуси с 1 июля 2016 года будет проведена деноминация
В Беларуси с 1 июля 2016 года будет проведена деноминация. Александр Лукашенко 4 ноября подписал указ № 450 «О проведении деноминации официальной денежной единицы Республики Беларусь». Об этом сообщает пресс-служба президента Беларуси.
Указом предписано провести с 1 июля 2016 года деноминацию официальной денежной единицы Республики Беларусь и произвести замену по 31 декабря 2016 года обращающихся денежных знаков образца 2000 года в виде банкнот на денежные знаки образца 2009 года в виде банкнот и монет в соотношении 10 тыс. рублей в образцах 2000 года к 1 рублю в денежных знаках образца 2009 года.
Памятные банкноты, выпущенные в обращение Национальным банком, с 1 июля 2016 года подлежат приему при всех видах платежей без ограничений в соотношении, указанном выше, памятные и слитковые (инвестиционные) монеты, выпущенные в обращение Нацбанком, подлежат приему по нарицательной стоимости при всех видах платежей без ограничений.
Указом устанавливается, что 1 белорусский рубль образца 2009 года равен 100 белорусским копейкам образца 2009 года.
Как жить дальше? :)
Указом предписано провести с 1 июля 2016 года деноминацию официальной денежной единицы Республики Беларусь и произвести замену по 31 декабря 2016 года обращающихся денежных знаков образца 2000 года в виде банкнот на денежные знаки образца 2009 года в виде банкнот и монет в соотношении 10 тыс. рублей в образцах 2000 года к 1 рублю в денежных знаках образца 2009 года.
Памятные банкноты, выпущенные в обращение Национальным банком, с 1 июля 2016 года подлежат приему при всех видах платежей без ограничений в соотношении, указанном выше, памятные и слитковые (инвестиционные) монеты, выпущенные в обращение Нацбанком, подлежат приему по нарицательной стоимости при всех видах платежей без ограничений.
Указом устанавливается, что 1 белорусский рубль образца 2009 года равен 100 белорусским копейкам образца 2009 года.
Как жить дальше? :)
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Хотя тут с коллегой пообщались. Просто перевести учет с деления на 10000 будет маловато. Самое простое решение свернуть базу и вести учет с 1 июля 2016 года. Но если нельзя, то придется еще и курс белорусского рубля изменить в валюте. Т.е. 1 июля 2016 года его сделать как 1, а до первого 1/10000.
Интересно, как будет формироваться бухгалтерский баланс в 1С...
Нужно будет перенести бухгалтерию 7.7, 8.2, ЗУП, Торговлю 2, Торговлю 3...
Пока совсем непонятно.
Закрыть период и все остатки регистров накопления разделить на 10000, также сделать со срезом последних регистров сведений....
Только когда закрывать период и делать это все в торговле? 31 июня ночью?
В бухгалтерии, может быть, закрыть все счета в 00, и открыть заново только с суммами в 10000 раз меньшими? Как будут выглядеть акты сверки с контрагентами?
Также нужно будет какое-то время на ценниках печатать 2 цены...
Очень много работы, справиться бы :)
Нужно будет перенести бухгалтерию 7.7, 8.2, ЗУП, Торговлю 2, Торговлю 3...
Пока совсем непонятно.
Закрыть период и все остатки регистров накопления разделить на 10000, также сделать со срезом последних регистров сведений....
Только когда закрывать период и делать это все в торговле? 31 июня ночью?
В бухгалтерии, может быть, закрыть все счета в 00, и открыть заново только с суммами в 10000 раз меньшими? Как будут выглядеть акты сверки с контрагентами?
Также нужно будет какое-то время на ценниках печатать 2 цены...
Очень много работы, справиться бы :)
(12) svilsa, до 1 июля есть время на подумать, а с первого у вас будет пол года это доработать.
По поводу поделить. Тут я думаю вопрос в другом. Нужно будет кратность рубля увеличить на 10000. И ввести новый курс рубля с кратностью 1. Т.е. текущий рубль это 10 000 рублей текущих. Кратность как раз и покажет результат.
По поводу поделить. Тут я думаю вопрос в другом. Нужно будет кратность рубля увеличить на 10000. И ввести новый курс рубля с кратностью 1. Т.е. текущий рубль это 10 000 рублей текущих. Кратность как раз и покажет результат.
(16) gubanoff, что это даст. Сегодня у вас товар стоит 10000 рублей, кратность 1.
1 июля он у станет стоит, один рубль, кратность один, а 1 июня он у вас при новом раскладе будет стоить 0,0001 рубля, т.к. кратность уже будет 10000.
1 июля он у станет стоит, один рубль, кратность один, а 1 июня он у вас при новом раскладе будет стоить 0,0001 рубля, т.к. кратность уже будет 10000.
(18) gubanoff, поставьте копию базы и проверьте.
Это будет работать, только если запросы используют курс для бел рубля. Если запросы не будут использовать курс, то нужно будет менять запросы. Еще нужно будет сделать переоценку всей номенклатуры. Т.к. если товар будет стоить 10 000 рублей первого июля, то день назад он должен был стоять 100 000 000.
Так что не все так просто.
Это будет работать, только если запросы используют курс для бел рубля. Если запросы не будут использовать курс, то нужно будет менять запросы. Еще нужно будет сделать переоценку всей номенклатуры. Т.к. если товар будет стоить 10 000 рублей первого июля, то день назад он должен был стоять 100 000 000.
Так что не все так просто.
до 31 июня вести все по старому
создать чистую базу со старыми справочниками
внести в чистую базу остатки на 31.06.16 уже в новых единицах и дальше работать в новой
создать чистую базу со старыми справочниками
внести в чистую базу остатки на 31.06.16 уже в новых единицах и дальше работать в новой
(20), а как быть в бухгалтерии, когда бухгалтера 20 июля будут "закрывать" июнь и им с 1 июля по 20-е будут приходить акты на затраты 44 счета с суммами до деноминации? Как быть с начислением ЗП, когда в июле за июнь нужно еще, скорее всего, начислить в миллионах, а выплатить в июле уже в рублях. Тут скорее всего нужен "двойной" учет в двух базах в течении какого-то периода (минимум до 20 июля), либо до 20 июля все по-старому, а выполнить операции по сворачиванию и разворачиванию остатков нужно после 20-го июля.
(20) KontoraB, зачем вносить остатки. если можно просто свернуть копию старой и конвертировать сразу суммы. Но, две базы делать не вариант, не удобно сразу в двух вести учет, а если баз несколько, то вообще грусть. Были мысли про дубли регистров или ресурсов, но тоже слишком трудозатратно, другой вопрос как по другому с делать чтобы можно было выполнить такие операции как в 22 описаны, не понятно. По ходу будем ждать инструкций. Но все же надеюсь с 01.01.2017 сделают поправку, либо свертку с конвертацией и в работу.
А если после 01.07.2015 работать в базе по старому (без копеек), и только после того как период до 01.07 будет обработан и закрыт выполнить процедуру свертки базы (конечно во всех операциях после 01.07 придется обрезать нули. Конечно придется допилить все печатные формы, чтобы временно деление на 10000 осушествлялось в них при печати всех документов после 01.07.
(25) "А если после 01.07.2015 работать в базе по старому (без копеек), и только после того как период до 01.07 будет обработан и закрыт выполнить процедуру свертки базы (конечно во всех операциях после 01.07 придется обрезать нули".
А после того как период будет закрыт и выполнена процедура свертки базы - навсегда запретить отмену проведения и перепроведение старых документов (до 1.07) ???. У многих получится такой запрет для бухов реально реализовать ? Или после каждого перепроведения делать свертку базы по-новому ?
А после того как период будет закрыт и выполнена процедура свертки базы - навсегда запретить отмену проведения и перепроведение старых документов (до 1.07) ???. У многих получится такой запрет для бухов реально реализовать ? Или после каждого перепроведения делать свертку базы по-новому ?
(39) GraySg, ну да, вобщем-то это стандартная ситуация при любой свертке базы. Раз уж приняли решение и базу (остатки) свернули, то последующие изменения в закрытом периоде либо не делать в принципе, либо делать при помощи корректировок в текущем периоде, либо придется заново потом сворачивать базу (остатки). Есть еще вариант обрезки нулей во всех регистрах и документах в ночь с 30 июня на 01 июля (с увеличением разрядности реквизитов для того чтобы не потерять точность), тогда можно работать себе в ранних периодах сколько угодно (работая уже с копейками). Но этот вариант тоже на любителя :)
И еще мысли в слух - а если тупо обрезать нули во всех документах и регистрах (понятно что надо анализировать в каких реквизитах и по каким условиям)? И можно обойтись без свертки и даже редактировать старые документы )). Минус только один - за счет округлений повылазят в остатках копейки во всех регистрах (( (например по давно отгруженным позициям ТМЦ и т.д.). Но это уже проблема решаемая
Раскроем тему поглубже :)
План доработок по деноминации
Варианты перехода:
1. перенести остатки в новую, подготовленную базу
1.1. нужно писать обработки по переносу
1.2. сам перенос может занять большое время
1.3. нужно будет работать с двумя базами
1.4. большой объем данных для переноса, т.к. желательно перенести все
2. удалить старые периоды в существующей базе («обрезать» базу)
2.1. аналогично предыдущему варианту
3. сконвертировать существующую базу к новым ценам («поделить все на 10000»)
3.1. может занять длительное время
3.2. параллельно нужно все-таки оставить архив старой исходной базы для сверки и подстраховки
3.3. данные старых периодов будут безвозвратно приведены к новым ценам
4. скорректировать остатки в разрезе аналитики к новым ценам оборотами. Т.е. для бухгалтерии это значит сделать корректирующую проводку на разницу, чтобы на 01.07 сальдо было в новых ценах, а на 30.06 сальдо осталось в старых ценах
4.1. самый быстрый вариант
4.2. подойдет ли для не бухгалтерских задач? зарплата, прочее?
4.3. возможность ручного редактирования, если где-то не устраивает получившаяся проводка
4.4. проблемы с получением отчетов за весь год
4.4.1. возможно, этой проблемы и не будет. Будет отдельное формирование отчетов за полугодия
4.5. проблемы с алгоритмами программ, которые опираются на данные прошлых периодов, в том числе проблема оборотных регистров. Нужно будет в них делить на 10000 старые цифры. Это существенная доработка отчетов.
Проблемы, которые надо решить при переходе:
1. В регистрах, документах и прочих метаданных установить разрядность минимум в 2 знака после запятой для учета копеек
1.1. можно делать заранее, оставив пока округление до 1. Потом убрать округление
1.2. сразу после этой операции возникнут проблемы в расчетах сумм, т.к. не во всех формулах принудительно происходит округление до 1. Нужно проверить все формулы, все записи в регистры.
2. В печатных формах установить формат вывода сумм с 2 знаками после запятой, вывод сумм прописью изменить с учетом копеек
2.1. форматы и прописи можно вынести в общие процедуры, чтобы до деноминации работал старый вариант, а после новый. А также чтобы заранее начать эту работу.
3. Деноминировать остатки в регистрах
3.1. разделить все суммы на 10000
3.1.1. при этой операции теряется точность сумм
3.1.1.1. результат округления отнести на соответствующие счета в бухучете (на это, скорее всего, будут разъяснения)
3.1.1.2. куда относить результат округления в других, не бухгалтерских регистрах?
3.1.1.3. исключить потерю точности сумм, добавив разрядность в 4 знака или больше (насчет большей разрядности также возможны разъяснения, возможно, будут использоваться доли копейки, см. пункт про российские рубли)
3.1.2. обработка регистров в старых базах займет огромное количество времени
4. Деноминировать суммы в документах, справочниках и т.п.
4.1. в старых данных нужно пересчитать все суммы
4.1.1. конкретно в документах можно не пересчитывать, обрабатывать эту ситуацию на этапе проведения – для старых документов делить суммы на 10000
4.2. запись данных займет огромное количество времени
5. С 01.07 все исходящие печатные формы должны быть в новых ценах, но бухгалтера еще не закрыли старые периоды
5.1. этой проблемы нет, документы будут вводиться и печататься в новых ценах
5.2. единственное, если все формы будут настроены на печать копеек, то старые формы тоже уже будут с ними выводиться
6. С 01.07 все исходящие печатные формы для населения должны будут выводить две суммы – с копейками и без
6.1. печать ценников – обязательно по Указу
6.2. расчетные листы, справки о доходах, в банк, другие формы?
6.3. в печатных формах умножать на 10000 суммы в копейках – это и будут новые цены
7. Учет валюты – на примере российского рубля, курс которого сейчас 273,86 рублей, а по новым ценам это будет 3 копейки (очень сильно округляется)
7.1. для физических лиц проблема решается кратностью – будут продавать/покупать минимум 100/1000 рублей
7.2. в расчетах юридических лиц все равно будут суммы в рублях (не округленные до 100 рублей), поэтому тут нужны разъяснения
8. Формирование двух балансов в 2016 году (скорее всего, так и будет)
8.1. все отчетные годовые формы будут подаваться за первое полугодие
План доработок по деноминации
Варианты перехода:
1. перенести остатки в новую, подготовленную базу
1.1. нужно писать обработки по переносу
1.2. сам перенос может занять большое время
1.3. нужно будет работать с двумя базами
1.4. большой объем данных для переноса, т.к. желательно перенести все
2. удалить старые периоды в существующей базе («обрезать» базу)
2.1. аналогично предыдущему варианту
3. сконвертировать существующую базу к новым ценам («поделить все на 10000»)
3.1. может занять длительное время
3.2. параллельно нужно все-таки оставить архив старой исходной базы для сверки и подстраховки
3.3. данные старых периодов будут безвозвратно приведены к новым ценам
4. скорректировать остатки в разрезе аналитики к новым ценам оборотами. Т.е. для бухгалтерии это значит сделать корректирующую проводку на разницу, чтобы на 01.07 сальдо было в новых ценах, а на 30.06 сальдо осталось в старых ценах
4.1. самый быстрый вариант
4.2. подойдет ли для не бухгалтерских задач? зарплата, прочее?
4.3. возможность ручного редактирования, если где-то не устраивает получившаяся проводка
4.4. проблемы с получением отчетов за весь год
4.4.1. возможно, этой проблемы и не будет. Будет отдельное формирование отчетов за полугодия
4.5. проблемы с алгоритмами программ, которые опираются на данные прошлых периодов, в том числе проблема оборотных регистров. Нужно будет в них делить на 10000 старые цифры. Это существенная доработка отчетов.
Проблемы, которые надо решить при переходе:
1. В регистрах, документах и прочих метаданных установить разрядность минимум в 2 знака после запятой для учета копеек
1.1. можно делать заранее, оставив пока округление до 1. Потом убрать округление
1.2. сразу после этой операции возникнут проблемы в расчетах сумм, т.к. не во всех формулах принудительно происходит округление до 1. Нужно проверить все формулы, все записи в регистры.
2. В печатных формах установить формат вывода сумм с 2 знаками после запятой, вывод сумм прописью изменить с учетом копеек
2.1. форматы и прописи можно вынести в общие процедуры, чтобы до деноминации работал старый вариант, а после новый. А также чтобы заранее начать эту работу.
3. Деноминировать остатки в регистрах
3.1. разделить все суммы на 10000
3.1.1. при этой операции теряется точность сумм
3.1.1.1. результат округления отнести на соответствующие счета в бухучете (на это, скорее всего, будут разъяснения)
3.1.1.2. куда относить результат округления в других, не бухгалтерских регистрах?
3.1.1.3. исключить потерю точности сумм, добавив разрядность в 4 знака или больше (насчет большей разрядности также возможны разъяснения, возможно, будут использоваться доли копейки, см. пункт про российские рубли)
3.1.2. обработка регистров в старых базах займет огромное количество времени
4. Деноминировать суммы в документах, справочниках и т.п.
4.1. в старых данных нужно пересчитать все суммы
4.1.1. конкретно в документах можно не пересчитывать, обрабатывать эту ситуацию на этапе проведения – для старых документов делить суммы на 10000
4.2. запись данных займет огромное количество времени
5. С 01.07 все исходящие печатные формы должны быть в новых ценах, но бухгалтера еще не закрыли старые периоды
5.1. этой проблемы нет, документы будут вводиться и печататься в новых ценах
5.2. единственное, если все формы будут настроены на печать копеек, то старые формы тоже уже будут с ними выводиться
6. С 01.07 все исходящие печатные формы для населения должны будут выводить две суммы – с копейками и без
6.1. печать ценников – обязательно по Указу
6.2. расчетные листы, справки о доходах, в банк, другие формы?
6.3. в печатных формах умножать на 10000 суммы в копейках – это и будут новые цены
7. Учет валюты – на примере российского рубля, курс которого сейчас 273,86 рублей, а по новым ценам это будет 3 копейки (очень сильно округляется)
7.1. для физических лиц проблема решается кратностью – будут продавать/покупать минимум 100/1000 рублей
7.2. в расчетах юридических лиц все равно будут суммы в рублях (не округленные до 100 рублей), поэтому тут нужны разъяснения
8. Формирование двух балансов в 2016 году (скорее всего, так и будет)
8.1. все отчетные годовые формы будут подаваться за первое полугодие
gubanoff, браво! Респект за твой труд! Всеобъемлюще и по существу!
Пока склоняюсь к варианту 3, осталось только опытным путем определить требуемое на эту операцию время.
Есть вероятность что оно будет исчисляться в сутках ((
И по пункту 5.1 - проблема возникает, когда в печатной форме документа фигурирует не цена, а себестоимость (например в заказ-наряде СТО, когда материал иногда списывается по себестоимости). Т.е. на момент печати заказ-наряда надо иметь "актуальную" себестоимость, которая зависит в том числе и от операций, которые могут вноситься в июне (например допрасходы)
Пока склоняюсь к варианту 3, осталось только опытным путем определить требуемое на эту операцию время.
Есть вероятность что оно будет исчисляться в сутках ((
И по пункту 5.1 - проблема возникает, когда в печатной форме документа фигурирует не цена, а себестоимость (например в заказ-наряде СТО, когда материал иногда списывается по себестоимости). Т.е. на момент печати заказ-наряда надо иметь "актуальную" себестоимость, которая зависит в том числе и от операций, которые могут вноситься в июне (например допрасходы)
(29) kiba, не вижу никаких проблем. в июле у тебя все уже будет лежать в конвертированном виде. соответственно ввод данных так же будет осуществляться в таком же виде, и в любом случае печататься уже будет все с копейками. И главное в процессе доработок надо понимать, что нужно все сделать так чтобы потом можно было легко переключить формат с разардностью, т.к. копейки думаю долго не будут в обороте.
YuriFm, это да, но при условии что в ночь с четверга 30.06 на пятницу 01.07 удастся конвертнуть всю базу (обрезать нули в документах и во всех регистрах). Учитывая объем базы за 7 лет, причем у нас это далеко не одна база, это не факт ))
Или пятницу придется делать выходным, за три дня точно можно все успеть )))
Или пятницу придется делать выходным, за три дня точно можно все успеть )))
(33) Xershi, случится. Если к 01.07 не добавить хотя бы копейки (базу можно не конвертировать), то нельзя будет распечатать первичку с копейками. А первичка печатается каждый день и в некоторых организациях в огромных объемах. Если у вас торговля, то ценники с двумя ценами должны быть готовы еще раньше.
все правильно, на 1.07 уже все должно быть с копейками т.е. база должна быть конвертирована, так что можно и раньше выполнить эту задачу например начать где-нибудь в июне(середина). по з.п. то точно надо будет в июне, в силу того что з.п. за июнь надо будет выплачивать уже с копейками :)
(35) YuriFm, причем если документы старые можно (и нужно) конвертировать заранее, то регистры конвертировать заранее не получится, т.к. их данные учавствуют при оперативном проведении документов (расчет себестоимости и т.д.). Это только в ночь с 30.06 на 01.07 :)
Либо, как я писал выше, спокойно работать себе по старому (выводя в печатных формах все деленное на 10000), и конвертироваться после часа X, когда период до 01.07 будет обработан и закрыт.
Либо, как я писал выше, спокойно работать себе по старому (выводя в печатных формах все деленное на 10000), и конвертироваться после часа X, когда период до 01.07 будет обработан и закрыт.
Обратимся к истории - ПРИКАЗ МИНИСТЕРСТВА ФИНАНСОВ РЕСПУБЛИКИ БЕЛАРУСЬ от 12 ноября 1999 г. № 331 "Об утверждении Порядка отражения в бухгалтерском учете операций, связанных с деноминацией денежной единицы Республики Беларусь":
Министерство финансов Республики Беларусь устанавливает следующий порядок отражения в бухгалтерском учете операций, связанных с деноминацией денежной единицы Республики Беларусь.
1. Все юридические лица и индивидуальные предприниматели обязаны произвести пересчет стоимости активов, пассивов и остатков на забалансовых счетах в соотношении 1000 рублей к 1 рублю по состоянию на 1 января 2000 г.
2. Бухгалтерские отчеты и балансы за 1999 год составляются без учета деноминации. После этого пересчитываются в сторону уменьшения в 1000 раз стоимость активов, пассивов, остатков на забалансовых счетах, цены, тарифы, оклады, расценки и т.д. Вступительное сальдо на начало 2000 года в бухгалтерском учете изменяется в соотношении 1000 рублей к 1 рублю.
После завершения всех бухгалтерских записей составляется ведомость пересчета, которая сверяется с данными баланса и подписывается руководителем или собственником и главным бухгалтером.
3. В случае, когда при пересчете в результате округления стоимость отдельного инвентарного объекта, наименования запасов и др. оказывается нулевой по состоянию на 1 января 2000 г., то их следует принять к бухгалтерскому учету по условной оценке в рублях с двумя знаками после запятой.
Возникающие от пересчета суммовые разницы относятся на увеличение (уменьшение) источников собственных средств, в учреждениях, финансируемых за счет средств бюджета, - на увеличение (уменьшение) источников финансирования или соответствующих фондов.
4. Начиная с 1 января 2000 г. в бухгалтерском учете записи хозяйственных операций, в том числе расчетов за товары, отгруженные до 1 января 2000 г., оказанные до этого срока услуги и выполненные работы, а также расчетов по другим видам операций, платежи по которым не произведены, осуществляются исходя из новой нарицательной стоимости денежной единицы Республики Беларусь и нового масштаба цен.
5. В регистрах бухгалтерского учета за январь 2000 года следует указать стоимость объектов учета до деноминации, для чего ввести дополнительную графу «Стоимость на 01.01.2000 до деноминации».
Больше всего доставляет пятый пункт. А третий пункт как-бы намекает, что 4 знака после запятой могут быть реальны.
Министерство финансов Республики Беларусь устанавливает следующий порядок отражения в бухгалтерском учете операций, связанных с деноминацией денежной единицы Республики Беларусь.
1. Все юридические лица и индивидуальные предприниматели обязаны произвести пересчет стоимости активов, пассивов и остатков на забалансовых счетах в соотношении 1000 рублей к 1 рублю по состоянию на 1 января 2000 г.
2. Бухгалтерские отчеты и балансы за 1999 год составляются без учета деноминации. После этого пересчитываются в сторону уменьшения в 1000 раз стоимость активов, пассивов, остатков на забалансовых счетах, цены, тарифы, оклады, расценки и т.д. Вступительное сальдо на начало 2000 года в бухгалтерском учете изменяется в соотношении 1000 рублей к 1 рублю.
После завершения всех бухгалтерских записей составляется ведомость пересчета, которая сверяется с данными баланса и подписывается руководителем или собственником и главным бухгалтером.
3. В случае, когда при пересчете в результате округления стоимость отдельного инвентарного объекта, наименования запасов и др. оказывается нулевой по состоянию на 1 января 2000 г., то их следует принять к бухгалтерскому учету по условной оценке в рублях с двумя знаками после запятой.
Возникающие от пересчета суммовые разницы относятся на увеличение (уменьшение) источников собственных средств, в учреждениях, финансируемых за счет средств бюджета, - на увеличение (уменьшение) источников финансирования или соответствующих фондов.
4. Начиная с 1 января 2000 г. в бухгалтерском учете записи хозяйственных операций, в том числе расчетов за товары, отгруженные до 1 января 2000 г., оказанные до этого срока услуги и выполненные работы, а также расчетов по другим видам операций, платежи по которым не произведены, осуществляются исходя из новой нарицательной стоимости денежной единицы Республики Беларусь и нового масштаба цен.
5. В регистрах бухгалтерского учета за январь 2000 года следует указать стоимость объектов учета до деноминации, для чего ввести дополнительную графу «Стоимость на 01.01.2000 до деноминации».
Больше всего доставляет пятый пункт. А третий пункт как-бы намекает, что 4 знака после запятой могут быть реальны.
(38) "2. Бухгалтерские отчеты и балансы за 1999 год составляются без учета деноминации".
Тут хоть баланс в году не рвали пополам. Закрыли один год по старым ценам - открыли новый год с новыми.
А в 2016 пол-баланса будет в 10 000 раз больше другой половины. Как их совмещать ?
Что выводить в любом отчете с 1.06 по 31.07 ? Июнь в миллионах - июль с копейками ?
Какие минусы будут, если подойти полностью с противоположной стороны :
остатки не пересчитывать, новые суммы в документах с 1.07 умножать на 10 000 приводя к старым. А необходимые отчеты переписать : с 1.07 суммы делить на 10 000 ?
Закрыть год, и уже с 1 января пересчитать остатки и закрыть старую базу.
Тут хоть баланс в году не рвали пополам. Закрыли один год по старым ценам - открыли новый год с новыми.
А в 2016 пол-баланса будет в 10 000 раз больше другой половины. Как их совмещать ?
Что выводить в любом отчете с 1.06 по 31.07 ? Июнь в миллионах - июль с копейками ?
Какие минусы будут, если подойти полностью с противоположной стороны :
остатки не пересчитывать, новые суммы в документах с 1.07 умножать на 10 000 приводя к старым. А необходимые отчеты переписать : с 1.07 суммы делить на 10 000 ?
Закрыть год, и уже с 1 января пересчитать остатки и закрыть старую базу.
(41) GraySg,
закрыть старую базу
- этот вариант подходит только для сферических организаций в вакууме. Всегда есть корректировки и перерасчеты в старых периодах. Поэтому только делить все на 10000. Умножать смысла не вижу - что умножать? Суммы в регистрах? Так ведь многие отчеты берут данные из документов и из справочников. Умножать в отчетах? Это просто нереально. Если какие-то отчеты еще с горем пополам можно формировать, собирая старые и новые рубли и приводя все к одному, но 99% процентов других отчетов это просто не смогут. Все таблицы срезов, оборотов - все пропадает при таком подходе. Только физические таблицы, только хардкор :)
С 1-го июля также планируется ввести в действие систему обязательной регистрации электронных счет-фактур всеми плательщиками НДС.
(45) YuriFm, что это вы подразумаваете? :)
А вообще прикольно - 1-го июля деноминация и в этот же день необходимо всем обязательно зарегистрировать электронные счет-фактуры на портале МНС в новых деноминированных рублях... а разъяснений все еще нет
А вообще прикольно - 1-го июля деноминация и в этот же день необходимо всем обязательно зарегистрировать электронные счет-фактуры на портале МНС в новых деноминированных рублях... а разъяснений все еще нет
С точки зрения учета это отбрасывание лишних нулей. С точки зрения личных накоплений это замаскированное ограбление народа. Каждый год Мы с Вас за счет инфляции закрываем свои дыры в бюджете, а когда инфляция начинает "резать глаза" просто убираем нулики.
Какое бурное обсуждение.
С точки зрения бухгалтерии, налоговиков и домохозяек это кошмар.
А с точки зрения программиста - проблема выеденного яйца не стоит.
Создай новую валюту с новым кодом и всё...
Ну ещё сложный процесс обозвать её валютой учета.
С точки зрения бухгалтерии, налоговиков и домохозяек это кошмар.
А с точки зрения программиста - проблема выеденного яйца не стоит.
Создай новую валюту с новым кодом и всё...
Ну ещё сложный процесс обозвать её валютой учета.
(48) CaptainMorgan, нет, думаю, что все намного сложнее
Пока сама думаю, что придется в УТ-шках, Зупе - резать остатки регистров в 10000 раз. А бухгалтерию оставлять на всех "нулях" до конца года, но... думаю переписать правила обмена УТ-БП для того, чтобы новые документы с 1-го июля до 31 декабря 2016 года выгружались с умножением на 10000. УТ-ки думаю "резать" ночью на 1-е июля, чтобы менеджеры и продавцы утром пришли на работу - а у них уже все деноминировано эх)
Пока сама думаю, что придется в УТ-шках, Зупе - резать остатки регистров в 10000 раз. А бухгалтерию оставлять на всех "нулях" до конца года, но... думаю переписать правила обмена УТ-БП для того, чтобы новые документы с 1-го июля до 31 декабря 2016 года выгружались с умножением на 10000. УТ-ки думаю "резать" ночью на 1-е июля, чтобы менеджеры и продавцы утром пришли на работу - а у них уже все деноминировано эх)
(50)
Я это и подразумевал 9 постами сверху
чтобы новые документы с 1-го июля до 31 декабря 2016 года выгружались с умножением на 10000
Я это и подразумевал 9 постами сверху
новые суммы в документах с 1.07 умножать на 10 000 приводя к старым
Значит не только у меня такая мысль. Надо проработать детальнее.
На ЗУП также питаю надежду, что выйдет типовое обновление и все само деноминируется :) На УТ ни 2-ку, ни 3-ку надежд таких нет
А по-моему, в этом вопросе инициатива должна исходить от пользователей.
Если точнее - от бухгалтеров, финансистов и тех, кто отвечает за учет на предприятиях.
А дело программистов - заставить программу сделать то что нужно пользователю.
Но если пользователи сами этого не знают - так чего зря головы ломать?
Ведь пока нет ни инструкций минфина, ни требований руководства,
что бы мы ни делали - нет гарантии что результаты окажутся "правильными".
Если точнее - от бухгалтеров, финансистов и тех, кто отвечает за учет на предприятиях.
А дело программистов - заставить программу сделать то что нужно пользователю.
Но если пользователи сами этого не знают - так чего зря головы ломать?
Ведь пока нет ни инструкций минфина, ни требований руководства,
что бы мы ни делали - нет гарантии что результаты окажутся "правильными".
(53) LTrigubovich,
Пользователи (с которыми работаю) ждут предложения от меня, даже уверены в том, что я всё уже знаю и сделаю. Предлагать свои варианты и обсуждать их вместе - придется 100%
Но если пользователи сами этого не знают - так чего зря головы ломать?
Ведь пока нет ни инструкций минфина, ни требований руководства,
что бы мы ни делали - нет гарантии что результаты окажутся "правильными".
Ведь пока нет ни инструкций минфина, ни требований руководства,
что бы мы ни делали - нет гарантии что результаты окажутся "правильными".
Пользователи (с которыми работаю) ждут предложения от меня, даже уверены в том, что я всё уже знаю и сделаю. Предлагать свои варианты и обсуждать их вместе - придется 100%
Умножать - не выход. И тупо все делить в копии базы - тоже не выход. Полетят различные уровни аналитики. Например, общая задолженность контрагента, общая задолженность всех контрагентов. Надеюсь подготовить интеллектуальную обработку.
Мы решили что будем производить (после того как документы все до 01.07.2016 внесут в базу) физическую деноминацию всей базы (УПП за 8 лет) - деление на 10000 всех реквизитов регистров и документов, содержащих суммы в бел. рублях. С последующей корректировкой остатков регистров накопления и бухгалтерии (чтобы остатки на 01.07.2016 после обрезки были равны остаткам до обрезки / 10000). В результате вся база в копейках, работоспособность всех отчетов и всех алгоритмов за весь период, возможность перепроведения документов до 01.07 в крайних случаях. Также копия базы разворачивается "До деноминации", где можно посмотреть все в оригинальном виде ))
Ну и на промежуточный период с 01.7 до обрезки придется немного подшаманить печатные формы и отчеты (+ клиент-банк), где нужно чтобы копейки фигурировали.
Ну и на промежуточный период с 01.7 до обрезки придется немного подшаманить печатные формы и отчеты (+ клиент-банк), где нужно чтобы копейки фигурировали.
Думаю всю базу за 8 лет "перелопатить" (и регистры и проводки) - это "жесть".
У меня у самого база всего-лишь 4-х летняя, но при этом распределенная.
Так я ради интереса деноминировал одни только продажи и только за 3 месяца 16-го года.
И сколько Вы думаете простенькая такая обработка выполнялась (создать набор записей по регистратору, прочитать, разделить суммы, записать)?
Оказалось 1 час!
А сколько будут пересчитываться и партии товаров, и взаиморасчеты, и проводки, и у кого есть балансы дисконтных карт?
И не за 3 месяца, а за N лет?
Даже представить не могу :(
У меня у самого база всего-лишь 4-х летняя, но при этом распределенная.
Так я ради интереса деноминировал одни только продажи и только за 3 месяца 16-го года.
И сколько Вы думаете простенькая такая обработка выполнялась (создать набор записей по регистратору, прочитать, разделить суммы, записать)?
Оказалось 1 час!
А сколько будут пересчитываться и партии товаров, и взаиморасчеты, и проводки, и у кого есть балансы дисконтных карт?
И не за 3 месяца, а за N лет?
Даже представить не могу :(
(61) sommid, если делать через SQL, то нужно не забыть про пересчет итогов (это можно сделать потом в 1С, оно быстро выполняется). При перезаписи в 1С тоже можно немного сократить время за счет транзакций, выполнения в привилегированном серверном модуле, установке управляемых блокировок на весь регистр, использования РежимЗагрузки=Истина, отключения итогов на время перезаписи, пересчет итогов после записи. Плюс разделить это на несколько потоков для серверных баз. По итогу в несколько часов можно уложиться, так что печали тут нет.
При этом подходе возникла другая проблема: допустим у нас есть остаток по регистру 123456 рублей. Он сформировался 3086 записями приходов по 40 рублей каждая. Если мы каждую запись разделим на 10000, то получим 0 р 0 коп. Т.е. остаток будет 0. А должен был быть 12 р 34 коп. Получаем погрешность заметно большую, чем если бы мы делили только конечные остатки. Добавьте к этому, что такая погрешность будет накапливаться за счет прошлых лет, если учет ведется несколько лет. Вопрос, насколько это устроит бухгалтеров, такая большая погрешность.
(59) ваш подход - это деление остатков. Тут дополнительный регистр совсем не нужен. Просто делаете документ, который остатки регистра разделит на 10000 и сделает корректирующие записи.
При этом подходе возникла другая проблема: допустим у нас есть остаток по регистру 123456 рублей. Он сформировался 3086 записями приходов по 40 рублей каждая. Если мы каждую запись разделим на 10000, то получим 0 р 0 коп. Т.е. остаток будет 0. А должен был быть 12 р 34 коп. Получаем погрешность заметно большую, чем если бы мы делили только конечные остатки. Добавьте к этому, что такая погрешность будет накапливаться за счет прошлых лет, если учет ведется несколько лет. Вопрос, насколько это устроит бухгалтеров, такая большая погрешность.
(59) ваш подход - это деление остатков. Тут дополнительный регистр совсем не нужен. Просто делаете документ, который остатки регистра разделит на 10000 и сделает корректирующие записи.
(62) gubanoff,
Может можно дробную часть значений регистров оставить 4 знака после запятой, тогда ничего не потеряется?
А как именно можно разделить, например, данные документа (цены, скидки, НДС, суммы) "Реализация товаров и услуг" за 2013 г. в 1С "Управление торговлей"? (Тут, думаю, в крайнем случае можно воспользоваться "универсальным подбором и обработкой объектов", но на больших базах за большой период ничего не получится) А вот как разделить на 10000 движения этого документа по регистрам "партии товаров на складах", "взаиморасчеты", "товары в рознице" и др. без перепроведения? Как делить на 10000 суммы по движениям док-ов без перепроведения?
А может через КД2 попробовать? Сделать правила для идентичных конфигураций, а потом в правилах для табличных частей разделить источник на 10000... что только делать с движениями?
При этом подходе возникла другая проблема: допустим у нас есть остаток по регистру 123456 рублей. Он сформировался 3086 записями приходов по 40 рублей каждая. Если мы каждую запись разделим на 10000, то получим 0 р 0 коп. Т.е. остаток будет 0. А должен был быть 12 р 34 коп. Получаем погрешность заметно большую, чем если бы мы делили только конечные остатки. Добавьте к этому, что такая погрешность будет накапливаться за счет прошлых лет, если учет ведется несколько лет. Вопрос, насколько это устроит бухгалтеров, такая большая погрешность.
Может можно дробную часть значений регистров оставить 4 знака после запятой, тогда ничего не потеряется?
А как именно можно разделить, например, данные документа (цены, скидки, НДС, суммы) "Реализация товаров и услуг" за 2013 г. в 1С "Управление торговлей"? (Тут, думаю, в крайнем случае можно воспользоваться "универсальным подбором и обработкой объектов", но на больших базах за большой период ничего не получится) А вот как разделить на 10000 движения этого документа по регистрам "партии товаров на складах", "взаиморасчеты", "товары в рознице" и др. без перепроведения? Как делить на 10000 суммы по движениям док-ов без перепроведения?
А может через КД2 попробовать? Сделать правила для идентичных конфигураций, а потом в правилах для табличных частей разделить источник на 10000... что только делать с движениями?
(68) svilsa,
Может можно дробную часть значений регистров оставить 4 знака после запятой, тогда ничего не потеряется?
- так можно сделать, но в этом случае тоже возникает проблема - в регистре 4 знака, все ок, но при списании, например, материала, когда списывается все количество, нужно будет списать и всю сумму - т.е. сумму с 4 знаками. Но это не будет отражено в печатной форме, отчетах и т.п. Только в проводках. Такая вот нестыковка получается.
Как делить на 10000 суммы по движениям док-ов без перепроведения?
- работать с набором записей регистра примерно так:
НЗ = РегистрыНакопления[Строка.ИмяРегистра].СоздатьНаборЗаписей();
НЗ.Отбор.Регистратор.Установить(ВыборкаДетальныеЗаписи.Регистратор);
НЗ.Прочитать();
Если НЗ.Количество() > 0 Тогда
Для каждого Запись Из НЗ Цикл
Запись[ТекРесурс.ИмяРесурса] = Запись[ТекРесурс.ИмяРесурса] / 10000;
КонецЦикла;
НЗ.Записать(Истина);
КонецЕсли;
КонецЕсли;
Показать
Но вот какая идея мне пришла.
Не знаю даже - бредовая или гениальная :)
Попробую изложить, интересно ваше мнение:
А что если для всех регистров с суммами (которые надо будет деноминировать) создать "дубли"?
Например, если есть один регистр "ПартииТоваров" (допустим бухгалтерский).
В нем естественно какие-то движения, остатки, обороты - в текущих деньгах.
Пока до деноминации далеко, создаем еще один регистр партий "ПартииТоваров_Деноминация".
С теми же измерениями и ресурсами, и назначаем ему те же регистраторы, что и для исходного регистра.
Но, движений нигде не добавляем. По моей задумке он будет пустым до 1-го июля.
Кроме того, напишем простенькую обработку, которая получит остатки по исходному регистру на 01.07.2016,
разделит все что нужно на 10 000, и корректировкой записей регистров накопления загонит в новый регистр датой 30.06.2016 23:59:59.
На моей 4-хлетней базе такая обработка выполнилась за 2 минуты (а остатков партий там оказалось около 62 000 записей)!
И вот, в ночь на 1-е июля, запускаем эту обработку (можно регламентным заданием).
А после (или до ее запуска, смотря как написать) просто переименовываем регистр "ПартииТоваров" в "ПартииТоваровДоДеноминации", а "ПартииТоваров_Деноминация" переименовываем в "ПартииТоваров".
В результате, в ПартияхТоваров уже деноминированные остатки на 01.07, ВСЕ документы движений ТМЦ их анализируют и двигают, как и прежде, в модулях документов практически НИЧЕГО менять не надо!
А старые движения остаются в переименованном регистре и доступны в дальнейшем!
Единственное, что еще потребует немного времени, это сравнительно простая доработка некоторых отчетов.
И то лишь тех, которые запускаются за период в несколько месяцев сразу.
Но что стоит в запросы добавить "ОБЪЕДИНИТЬ" и добавить данные из переименованного регистра, разделенные на 10 000.
Ну, вот и вся идея.
Разумеется, аналогично придется поступить и с другими регистрами, и по нескольким регистрам возможно понадобится больше времени на выполнение обработки. Но партии товаров - один из самых "тяжелых", так что на остальные полагаю времени меньше понадобится (на каждый из них).
Не знаю даже - бредовая или гениальная :)
Попробую изложить, интересно ваше мнение:
А что если для всех регистров с суммами (которые надо будет деноминировать) создать "дубли"?
Например, если есть один регистр "ПартииТоваров" (допустим бухгалтерский).
В нем естественно какие-то движения, остатки, обороты - в текущих деньгах.
Пока до деноминации далеко, создаем еще один регистр партий "ПартииТоваров_Деноминация".
С теми же измерениями и ресурсами, и назначаем ему те же регистраторы, что и для исходного регистра.
Но, движений нигде не добавляем. По моей задумке он будет пустым до 1-го июля.
Кроме того, напишем простенькую обработку, которая получит остатки по исходному регистру на 01.07.2016,
разделит все что нужно на 10 000, и корректировкой записей регистров накопления загонит в новый регистр датой 30.06.2016 23:59:59.
На моей 4-хлетней базе такая обработка выполнилась за 2 минуты (а остатков партий там оказалось около 62 000 записей)!
И вот, в ночь на 1-е июля, запускаем эту обработку (можно регламентным заданием).
А после (или до ее запуска, смотря как написать) просто переименовываем регистр "ПартииТоваров" в "ПартииТоваровДоДеноминации", а "ПартииТоваров_Деноминация" переименовываем в "ПартииТоваров".
В результате, в ПартияхТоваров уже деноминированные остатки на 01.07, ВСЕ документы движений ТМЦ их анализируют и двигают, как и прежде, в модулях документов практически НИЧЕГО менять не надо!
А старые движения остаются в переименованном регистре и доступны в дальнейшем!
Единственное, что еще потребует немного времени, это сравнительно простая доработка некоторых отчетов.
И то лишь тех, которые запускаются за период в несколько месяцев сразу.
Но что стоит в запросы добавить "ОБЪЕДИНИТЬ" и добавить данные из переименованного регистра, разделенные на 10 000.
Ну, вот и вся идея.
Разумеется, аналогично придется поступить и с другими регистрами, и по нескольким регистрам возможно понадобится больше времени на выполнение обработки. Но партии товаров - один из самых "тяжелых", так что на остальные полагаю времени меньше понадобится (на каждый из них).
Кстати только вспомнил что появиться новая валюта. По итогу будет другой курс и вопрос будет решен очень быстро! Сейчас бур, а станет бун.
(64) Xershi, как бы вам покорректней объяснить, что валюта здесь не причем? Откройте любой регистр накопления - у вас там что, измерение "Валюта" есть? Прям во всех регистрах? Я думаю, что нет. Хорошо, даже по регистру бухгалтерии - у вас что, на всех счетах валютный учет? Я думаю, что нет. Поэтому и нужно приводить базу к новым ценам, валюта тут не поможет.
Что касается увеличения разрядности реквизитов регистров до 4 знаков - как-то раз приходилось столкнуться с последствиями такой операции.
Пришлось лопатить код, потому что в типовых механизмах тоже оказывается прописано приведение к разрядности 2 знака после запятой.
Осознав масштаб проблемы, вернули все назад )))
Пришлось лопатить код, потому что в типовых механизмах тоже оказывается прописано приведение к разрядности 2 знака после запятой.
Осознав масштаб проблемы, вернули все назад )))
Я может скажу глупость - что мешает добавить условный (с 01.07.16) коэффициент пересчета в печатные формы и выгрузки в инспекции, а полный переход выполнить 01.01.2017 ? Ну да, придется полгода мысленно работать в неденоминированных ценах, зато никаких ошибок округлений и масштабных переделок точности. А ближе к концу года в типовых конфигурациях переход не только разработают и отладят до состояния "можно пользовать".
(71) v3rter, выписка из банка уже будет приходить в новых ценах, документы от поставщиков уже будут приходить в новых ценах - придется их вносить с умножением на 10000? Тоже не совсем красиво.
На переходный период (пока не закроют июнь) - да, так и надо делать - все, что выходит из нашей базы делить на 10000, пока не сконвертировали базу. При этом все, что приходит в нашу базу вносить уже в новых ценах.
На переходный период (пока не закроют июнь) - да, так и надо делать - все, что выходит из нашей базы делить на 10000, пока не сконвертировали базу. При этом все, что приходит в нашу базу вносить уже в новых ценах.
Деление остатков на 10 000 - для 8.2.
А что делать в 7.7 (Бухгалтерия) ?
В стандартной свертке базы есть закладка "Деноминация".
Но она подразумевает разделение баз. Поэтому и делается обычно в конце года.
А тут получается, что за 1-е полугодие не останется проводок и только итоги / 10 000 на 31.06.
А что делать в 7.7 (Бухгалтерия) ?
В стандартной свертке базы есть закладка "Деноминация".
Но она подразумевает разделение баз. Поэтому и делается обычно в конце года.
А тут получается, что за 1-е полугодие не останется проводок и только итоги / 10 000 на 31.06.
(75) GraySg, можно и в 7.7 делить проводки, можно и в 8.2 делать свертку базы - тут по желанию, кому что больше нравится. А то, что это в середине года - я не вижу особой печали. Будут указания, как сдавать годовые отчеты, вот и все.
Свежее письмо от Нацбанка внесло ясность про вопрос:
Курс российского рубля будет устанавливаться с кратностью 100. И точность установки курсов, да, теперь 4 знака.
7. Учет валюты – на примере российского рубля, курс которого сейчас 273,86 рублей, а по новым ценам это будет 3 копейки (очень сильно округляется)
7.1. для физических лиц проблема решается кратностью – будут продавать/покупать минимум 100/1000 рублей
7.2. в расчетах юридических лиц все равно будут суммы в рублях (не округленные до 100 рублей), поэтому тут нужны разъяснения
7.1. для физических лиц проблема решается кратностью – будут продавать/покупать минимум 100/1000 рублей
7.2. в расчетах юридических лиц все равно будут суммы в рублях (не округленные до 100 рублей), поэтому тут нужны разъяснения
Курс российского рубля будет устанавливаться с кратностью 100. И точность установки курсов, да, теперь 4 знака.
Теперь осталось проверить весь нетиповой программный код на предмет использования в формулах расчета курса кратности ))
Возник вопрос по правильной (с точки зрения законодательства) переоценке себестоимости ТМЦ на складах.
В постановлении МИНФИНА Об округлении стоимости объекта учета (
говорится об округлении стоимости объекта учета, но в примере также приведено округление за Единицу материала, что сильно усложняет задачу.
на примере объекта учета "Гайка арт. М5"
Пример 1 (округляем общую стоимость остатка объекта учета):
До деноминации - остаток 100 шт., общая стоимость 100 рублей.
Если просто деноминировать общую стоимость 100 рублей, получится 1 копейка.
После деноминации - остаток 100 шт., общая стоимость 1 копейка.
Пример 2 (округляем цену ЕДИНИЦЫ объекта учета):
До деноминации - остаток 100 шт., общая стоимость 100 рублей.
Цена за 1 гайку = 100/100 = 1 рубль, делим на 10 000, получившееся значение округляем до 1 копейки,
умножаем на количество гаек.
После деноминации - остаток 100 шт., общая стоимость 100 копеек.
Кто что думает по этому поводу?
В постановлении МИНФИНА Об округлении стоимости объекта учета (
говорится об округлении стоимости объекта учета, но в примере также приведено округление за Единицу материала, что сильно усложняет задачу.
на примере объекта учета "Гайка арт. М5"
Пример 1 (округляем общую стоимость остатка объекта учета):
До деноминации - остаток 100 шт., общая стоимость 100 рублей.
Если просто деноминировать общую стоимость 100 рублей, получится 1 копейка.
После деноминации - остаток 100 шт., общая стоимость 1 копейка.
Пример 2 (округляем цену ЕДИНИЦЫ объекта учета):
До деноминации - остаток 100 шт., общая стоимость 100 рублей.
Цена за 1 гайку = 100/100 = 1 рубль, делим на 10 000, получившееся значение округляем до 1 копейки,
умножаем на количество гаек.
После деноминации - остаток 100 шт., общая стоимость 100 копеек.
Кто что думает по этому поводу?
(79) kiba, у нас похожая ситуация: на остатках числится 10 000 штук продукции собственного производства по цене 85 рублей общей суммой 850 000 руб. По правилам округления единицы продукции до 100 рублей для проведения деноминации должны возникнуть проводки:
Дт 43 Продукция1 Кт 90.07 15 * 10 000= 150 000 руб.
Для уменьшения сумм округления и обеспечения точности учета принято решение 30 июня провести фасовку продукции по 50 шт. В связи с чем возникнут проводки:
Дт 43 Продукция2 Кт 00 200 шт. 850 000 (цена продукции до деноминации в таком случае будет равна 4 250 руб)
Дт 43 Продукция1 Кт 00 -10 000 шт. -850 000
Для проведения деноминации добавится проводка:
Дт 43 Продукция2 Кт 90.07 200 * 50 = 10 000 руб.
Свертка остатков выполнит проводки:
Дт 43 Продукция2 Кт 00 -200 шт. -860 000 руб.
Дт 43 Продукция2 Кт 00 200 шт. 86 руб.
В итоге после деноминации цена единицы упаковки будет равна 43 копейки. А прочие доходы в связи с проведением деноминации составят 1 копейку вместо 15.
Дт 43 Продукция1 Кт 90.07 15 * 10 000= 150 000 руб.
Для уменьшения сумм округления и обеспечения точности учета принято решение 30 июня провести фасовку продукции по 50 шт. В связи с чем возникнут проводки:
Дт 43 Продукция2 Кт 00 200 шт. 850 000 (цена продукции до деноминации в таком случае будет равна 4 250 руб)
Дт 43 Продукция1 Кт 00 -10 000 шт. -850 000
Для проведения деноминации добавится проводка:
Дт 43 Продукция2 Кт 90.07 200 * 50 = 10 000 руб.
Свертка остатков выполнит проводки:
Дт 43 Продукция2 Кт 00 -200 шт. -860 000 руб.
Дт 43 Продукция2 Кт 00 200 шт. 86 руб.
В итоге после деноминации цена единицы упаковки будет равна 43 копейки. А прочие доходы в связи с проведением деноминации составят 1 копейку вместо 15.
(81) svilsa, фасовку будете проводить реально, или "виртуально", заведя фиктивную единицу измерения только для целей деноминации?
А что делать если таких видов продукции или материалов очень много, заниматься весь июнь их перефасовкой?
А что делать если таких видов продукции или материалов очень много, заниматься весь июнь их перефасовкой?
(83) kiba, фасовка продукции будет реальная, потому что продукция единицами не продается, а только комплектами. Просто до деноминации в прайсе были цены за 1 шт., а сейчас будут за комплект (коробка, туба) по 50/100/125 штук. А стоимость материалов, таких, как шурупы, которые используются для собственного потребления, будет округлена до 100 руб. документом автоматически независимо от итоговых сумм округления.
(79) с точки зрения Минфина только один вариант правильный - считаем цену, ее округляем до 1 копейки, умножаем на количество, получаем сумму. Да, будет большая разница. Но только так и нужно делать. Как вариант, разберитесь с этими суммами ДО деноминации - спишите или дооцените, можно создать комиссию и т.п. Или как в (81)
(82) этот франч выставил сумму только за обработку, которая разделит остатки, типа WRAP (я так думаю). Конечно же, в эту сумму не входит изменение всех реквизитов, печатных форм, округлений и т.п. Так клиенту и объясняйте.
(82) этот франч выставил сумму только за обработку, которая разделит остатки, типа WRAP (я так думаю). Конечно же, в эту сумму не входит изменение всех реквизитов, печатных форм, округлений и т.п. Так клиенту и объясняйте.
Я вот например думаю, что об этом в первую очередь должны думать главный бухгалтер и главный экономист.
Им известно - какое нарушение "сколько стоит".
Вот пусть и решают.
Возможно, оба пути допустимы, т.е. либо себестоимость 100 шт. округлить до копейки, и ждать пока эта копейка не спишется, либо себестоимость 1 шт. установить 1 коп. и получить "завышенную" себестоимость.
Если Минфин считает что можно и так и так, значит надо сделать как выгоднее предприятию.
Но в любом случае - это не программист решать должен.
Им известно - какое нарушение "сколько стоит".
Вот пусть и решают.
Возможно, оба пути допустимы, т.е. либо себестоимость 100 шт. округлить до копейки, и ждать пока эта копейка не спишется, либо себестоимость 1 шт. установить 1 коп. и получить "завышенную" себестоимость.
Если Минфин считает что можно и так и так, значит надо сделать как выгоднее предприятию.
Но в любом случае - это не программист решать должен.
Денежный вопрос: один из моих постоянных клиентов недавно обратился – попросили начать подготовку базы данных (7-ки) к деноминации. Конфигурация очень «мудрёная» и «тяжёлая». Годы доработок различными программистами, в том числе и мною.… Попросили сделать расчёт суммы за работу. По нормо-часам вышло около 60-ти часов на всё. С учётом скидки выставил 20 млн+НДС. Несколько дней назад перезвонили – говорят, обратились к франчу (не буду говорить к какому) – те им пообещали всё сделать за день! Ну и комм.предложение скинули им в р-не 3 млн. Сижу и думаю – то ли я зажрался со своими расценками, то ли франчи за еду работают… Есть еще мысль: может есть какой то механизм который автоматом метаданные шерстит, формы, формулы сам меняет…(из разряда фантастики). Короче в лёгком недоумении. Может, кто прояснит ситуацию…??
P.s. – конфа действительно сложная – около 90 уникальных документов со своими эксклюзивными расчётами и печатными формами… + справочники, обработки, константы, формы…
P.s. – конфа действительно сложная – около 90 уникальных документов со своими эксклюзивными расчётами и печатными формами… + справочники, обработки, константы, формы…
(82) 1v7, глупый менеджер скинул предложение на типовую конфигурацию.
Так что заказчик, то не знает о чем ему говорили, а вы не знаете, что он им говорил. Когда узнаете, можете вернуться к вопросу. Ну ждите, когда он решит прибежать к вам.
А так франчи могут и продешевить, до определенной суммы. Когда им будет известен фронт работы, тогда будет и другая сумма 100%!
Так что заказчик, то не знает о чем ему говорили, а вы не знаете, что он им говорил. Когда узнаете, можете вернуться к вопросу. Ну ждите, когда он решит прибежать к вам.
А так франчи могут и продешевить, до определенной суммы. Когда им будет известен фронт работы, тогда будет и другая сумма 100%!
(84) Xershi, Немного обидно, что в глазах заказчика - я счас жадный и неблагодарный ИП-шник который выставил сумму в 7 раз выше, чем франчайзи...Подождать то подождём, но уже в очереди стоят новые клиенты, а на этого заказчика времени потом не будет. А с ними я работал с 2007...
(85) 1v7, Здравствуйте, может проясните ситуацию по свертке базы Бухгалтерия 1С 7.7(к 1 июля 2016 Готовимся к Деноминации)- В результате свертки формируются операции( сальдо по счетам на Дату)- На Дату-1 , как я понимаю нужно удалить все документы чтобы не было задваивания сумм- но тогда в операции, например счет 45( Товары отгруженные) Субконто3(отгрузочные документы)-выдает "Объект не найден".Или я что-то неправильно-понимаю ?Спасибо если кто-то подскажет!
(88) oks25, Скачайте обработку .
Она также есть в некоторых конфигурациях или в папке ExtForms (по умолчанию)...
В копии (!) базы запустите WRAP.ert
1) делаете свёртку (ставите признак - помечать документы на удаление) (1-я вкладка WRAP.ert)
2) c помощью стандартной обработки(из сервиса) - удаляете помеченные (ни где не участвующие) документы.
3) потом деноминацию (2-я вкладка WRAP.ert)
если кратко - то как-то так. СУБКОНТО3 НА 45 НЕ ДОЛЖНО ПРОПАСТЬ! если удалять стандартной обработкой(из сервиса) - они остануться в базе помеченными на удаление...
я своим клиентам такой алгоритм предлагаю:
Она также есть в некоторых конфигурациях или в папке ExtForms (по умолчанию)...
В копии (!) базы запустите WRAP.ert
1) делаете свёртку (ставите признак - помечать документы на удаление) (1-я вкладка WRAP.ert)
2) c помощью стандартной обработки(из сервиса) - удаляете помеченные (ни где не участвующие) документы.
3) потом деноминацию (2-я вкладка WRAP.ert)
если кратко - то как-то так. СУБКОНТО3 НА 45 НЕ ДОЛЖНО ПРОПАСТЬ! если удалять стандартной обработкой(из сервиса) - они остануться в базе помеченными на удаление...
я своим клиентам такой алгоритм предлагаю:
(90) chesnok, Вы правы. перепутал. недавно дорабатывал авторскую восьмёрку - вот и застрял в мозгу алгоритм...спасибо.
для oks25:
В копии (!) базы запустите WRAP.ert
1) делаете свёртку (ставите признак - помечать документы на удаление) с деноминацией (коэф.10000)
2) c помощью стандартной обработки(из сервиса) - удаляете помеченные (ни где не участвующие) документы.
для oks25:
В копии (!) базы запустите WRAP.ert
1) делаете свёртку (ставите признак - помечать документы на удаление) с деноминацией (коэф.10000)
2) c помощью стандартной обработки(из сервиса) - удаляете помеченные (ни где не участвующие) документы.
(94) Slypower, так чтобы одна обработка всё сделала - я не нашёл. Делаю всё двумя стандартными обработками(через XML) + самопис.
Но у меня все 7-ки. 8-ка только одна и та очень сильно не типовая... Кстати от Юколы сегодня новость прочел. Толкают какой-то механизм для деноминации 8-ки за 30 мультов)
Но у меня все 7-ки. 8-ка только одна и та очень сильно не типовая... Кстати от Юколы сегодня новость прочел. Толкают какой-то механизм для деноминации 8-ки за 30 мультов)
(103) Slypower, почему нет. вот кто то, что то похожее сделал на 8-ке . но я не скачивал - не знаю как работает. Свернуть базу не проблема. Проблема её доработать - чтобы корректно считала с копейками и формы выдавала.
(105) gubanoff, у меня нет единого механизма для 8-ки. 20 млн это около 60-70 часов фактически затраченных на ручное ковыряние и перевод на BYN совсем не типовой конфигурации... против цен франчей ни чего против не имею. мне от этого только лучше
з.ы. - что-то мне подсказывает что за 30 мультов они толкают какое то типовое решение(типо супер обработки), которое многим не подойдёт.
(105) gubanoff, у меня нет единого механизма для 8-ки. 20 млн это около 60-70 часов фактически затраченных на ручное ковыряние и перевод на BYN совсем не типовой конфигурации... против цен франчей ни чего против не имею. мне от этого только лучше
з.ы. - что-то мне подсказывает что за 30 мультов они толкают какое то типовое решение(типо супер обработки), которое многим не подойдёт.
Переоценка себестоимости запасов должна проводиться согласно ведомости пересчета остатков объектов учета.
Тут возникает вопрос технического характера как реализовать эту ведомость и последующий пересчет стоимости запасов на склада согласно ее данных- что является объектом учета и что является источником данных для этой ведомости?
На примере УПП.
По данным регистра бухгалтерии (ОСВ по счету 10), объектом учета выступает укрупненно Склад/Номенклатура - одна позиция.
По данным регистра партии товаров на складах,объектом учета уже выступает Склад/Номенклатура/Характеристика/Серия/Партия - много позиций.
Если используется РАУЗ, то там свои заморочки.
Вопрос - цену объекта учета и сам объект учета для ведомости пересчета откуда брать?
Из данных ОСВ (одну позицию укрупненно) и подгонять все остатки по партиям товаров под цену из ведомости (т.е. по всем партиям например цена получится одинаковая).
Или тянем в ведомость данные из регистра по партиям товаров на складах в разрезе каждой аналитики, и подгоняем потом уже регистр бухгалтерии (прописываем туда среднюю цену).
Тут возникает вопрос технического характера как реализовать эту ведомость и последующий пересчет стоимости запасов на склада согласно ее данных- что является объектом учета и что является источником данных для этой ведомости?
На примере УПП.
По данным регистра бухгалтерии (ОСВ по счету 10), объектом учета выступает укрупненно Склад/Номенклатура - одна позиция.
По данным регистра партии товаров на складах,объектом учета уже выступает Склад/Номенклатура/Характеристика/Серия/Партия - много позиций.
Если используется РАУЗ, то там свои заморочки.
Вопрос - цену объекта учета и сам объект учета для ведомости пересчета откуда брать?
Из данных ОСВ (одну позицию укрупненно) и подгонять все остатки по партиям товаров под цену из ведомости (т.е. по всем партиям например цена получится одинаковая).
Или тянем в ведомость данные из регистра по партиям товаров на складах в разрезе каждой аналитики, и подгоняем потом уже регистр бухгалтерии (прописываем туда среднюю цену).
Всем привет. У нас примерно такая схема деноминации УТ3:
1. Сделать пустую базу.
2. Сделать формат переменных и полей 6 знаков после запятой. (да, потому что у нас есть суммы 12356,82 BYR - после деноминации 1,235682. Бухи "мамой клэнус", что так и надо). Чтобы не потерять копейки. Сделал обработку, которая шуршит по метаданным и выводит список полей и форматы чисел. Руками изменить точность хранения в конфигурации.
3. Конвертацией данных перенести все регистры и справочники с масштабом 10000.
4. Перенести остатки на 01.01.2016 в деноминированных суммах.
5. Настроить план обмена старая база -> новая база в соответствии с правилами конвертации. Для того, чтобы все изменения в старой базе отражались в новой.
6. Ночью на сервере 1С переключить указатель базы со старой на новую.
7. 01.07.2016 провести корректировку остатков регистров с округлением ,2
Расскажите, пожалуйста, где меня ждет облом?
1. Сделать пустую базу.
2. Сделать формат переменных и полей 6 знаков после запятой. (да, потому что у нас есть суммы 12356,82 BYR - после деноминации 1,235682. Бухи "мамой клэнус", что так и надо). Чтобы не потерять копейки. Сделал обработку, которая шуршит по метаданным и выводит список полей и форматы чисел. Руками изменить точность хранения в конфигурации.
3. Конвертацией данных перенести все регистры и справочники с масштабом 10000.
4. Перенести остатки на 01.01.2016 в деноминированных суммах.
5. Настроить план обмена старая база -> новая база в соответствии с правилами конвертации. Для того, чтобы все изменения в старой базе отражались в новой.
6. Ночью на сервере 1С переключить указатель базы со старой на новую.
7. 01.07.2016 провести корректировку остатков регистров с округлением ,2
Расскажите, пожалуйста, где меня ждет облом?
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот