BSU обработка нулира регистрите за натрупване. Нулиране на салда и движения на натрупващи регистри (UF)

Решихме по някакъв начин да възстановим реда в конфигурацията на UT версия 11. И там ... Салдата на стоките не съвпадат с балансите на организациите (използват се няколко организации), а с пратки стоки те изобщо не са близки и дори комисионната търговия се използва заедно с редовната търговия. Накратко, всичко е толкова занемарено, че е по-лесно да се започне от нулата, НО... Не можете да започнете от нулата - има връзка с корпоративното счетоводство 3.0 (справочници, документи) и там отчетът вече е подаден. Решихме отделно да сложим ред в счетоводството и отделно в счетоводството. Конкретно за UT решихме: нулираме всичко, свързано със стоки (стоки в склада, стоки на организации, пратки със стоки на организации, плюс регистри, свързани с комисионната), след това правим фиктивна разписка (включително за комисионна), и коригираме взаимните разплащания чрез коригиране на взаимните разчети. Първо започнах да пиша обработка за конкретни регистри, докато пишех, мислех да напиша универсален за приблизително същото време, но да е подходящ за всички регистри, за да не се налага да го пренаписвам десет пъти по-късно . Също така трябва да е подходящ за Retail 2, Complex и други конфигурации за управлявани форми. Тестван на UT11.

Как да използвам. Първо, създаваме ръчно празен документ за „корекция на регистъра“, задаваме датата и часа (зададох 23:59:59 в края на тримесечието), балансите в регистъра ще бъдат отведени точно на тази позиция (позиция на документа), в общо взето, от документа ни трябват само позицията и необходимите. След това избираме кои регистри трябва да нулираме и натискаме „Генериране“. Отваряме корекцията, разглеждаме, проверяваме регистрите с помощта на отчети и/или универсален отчет. Салдата са затворени за всички измерения и за всички ресурси. Също така във формуляра има избор по организация и склад (връщане от оригиналната версия, но работи), не добавих други селекции (тъй като изобщо не ми трябваше), който има нужда, може добавете го сами, всичко е ясно написано в модула, а не аз започнах да го използвам, защото например, ако направите избор по организация, тогава за регистъра „Стоки на организации“ изборът ще работи, но за регистъра „ Стоки в складове” няма (няма такова измерване), затова го нулирах без избор.

Мина известно време...

Излезе нова версия, сега обработката се научи (преди това даде грешка - тоест всъщност работеше само с балансови регистри) за обръщане на движенията в циркулиращия натрупващ регистър. Освен това движенията са обратни, т.е. ако погледнете регистъра, да речем „Продажби“ в UT11, тогава след сторниране продажбите изобщо няма да се показват, т.е. сякаш изобщо не е имало продажби - оборотът като цяло за периода ще е празен. Още веднъж - оказва се, например имаме продажби за периода 1-30 януари, на 31-ви правя сторно, след това като погледна справката от 1 до 30 - ще видя продажби, от 31 до 31 - Ще видя обратни движения, от 1- 31 - ще покаже празно. Например, обърнах движенията на „Каса“ в UT11 и Retail 2.2, когато трябваше да подредя „Каса“ (50 сметка, кой знае).

Да, забравих да кажа, появи се полето "Начална дата" - служи за задаване на начална дата на периода за оборотни регистри (за салда, разбира се, не важи), позицията на документа "Корекция на регистъра" се използва като крайна дата на периода (за оборотни регистри) - т.е. както за балансовия регистър (салдата се отстраняват в позицията на документа). За оборотните регистри „Началната дата“ може да остане празна - в този случай тя се възприема като най-ранната дата, която може да съществува, а за оборотния регистър това ще означава, че всички движения от началото на счетоводството до позицията на „ Корекция на регистрите” са сторнирани.

Добра новина - цената в точки е намаляла.

• Бързо и удобно нулиране на баланси;
• Опростени и разширени интерфейси;
• Поддръжка на натрупващи и счетоводни регистри(включително с активирана и деактивирана кореспонденция; със и без сметкоплан);
• Поддържа повечето конфигурации;
• Възможност за работа с всякакви конфигурационни регистри, не само със стандартни;
• Гъвкави настройки за избор(избор по размери, детайли, ресурси, както и по техните вложени полета. Използване на групи “И”, “ИЛИ”, “НЕ”. На базата на ACS);
• Възможността да нулирате не всичко, но само необходимите ресурси;
• Попълване на полетата кор. сметкиза счетоводния регистър (подсметка, задбалансови измервания и ресурси), както и всякакви подробности с избрани стойности;
• Възможност за избор на вида на документа за корекция (ако конфигурацията ви позволява да коригирате регистъра с няколко вида документи);
• Възможност за запис на движения в нов или вече създаден документ;
• Поддръжка на множество режимивърши работа:
  • Възстановяема сметка в Dt (за счетоводни регистри);
  • Възстановяема сметка в Kt (за счетоводни регистри);
  • Положителни стойности на ресурсите;
  • Отрицателни стойности на ресурсите.
• Работете в нестандартни конфигурации (ако добавите стандартен документ за настройка на конфигурацията (от списъка на поддържаните) към него);
• Гъвкав интерфейс: показват се само онези полета, които са необходими в текущата конфигурация за избрания регистър;
• Свързаносткато външна обработка.

Преглед

Обработката се отваря в прост интерфейс по подразбиране. Съдържа минимум полета и ви позволява да нулирате целия регистър. Ако имате нужда от повече настройки, трябва да кликнете върху бутона „Активиране на разширен режим“.

Интерфейсът за разширен режим може да бъде разделен на няколко части:

1. Полета за избор на случай.

Падащият списък с имена на регистри включва всички регистри, с изключение на оборотните регистри (те нямат салда).

2. Полета за настройка на документа за корекция.

В зависимост от ситуацията някои от тях може да са скрити.
Специално внимание трябва да се обърне на полето „Направете корекции в документа...“. В него можете да изберете един от режимите на формиране на движение:

• Всички движения с изглед "Входящи" (режим за натрупващи регистри);
• Всички движения с изглед "Потребление" (режим за натрупващи регистри);
• Възстановяема сметка в Dt (за счетоводни регистри). Документът за корекция ще генерира транзакции от формуляра Dt<Счет>CT<КоррСчет> ;
• Нулируема сметка в Kt (за счетоводни регистри). Документът за корекция ще генерира транзакции от формуляра Dt<КоррСчет>CT<Счет> ;
• Положителни стойности на ресурс (този режим е полезен, например, когато отрицателните суми не могат да бъдат записани в регистъра);
• Отрицателни стойности на ресурсите (ако трябва да намалите оборота при нулиране).

3. Нулирайте датата и полетата на документа за корекция.

В полето "Нулиране на салда към дата" следва да посочите датата и часа, за които ще бъдат получени салдата за нулиране. При получаване на остатъци движението се включва в последната секунда.
В зависимост от вида на документа за корекция ще бъдат налични полетата „Коментар“ и/или „Организация“. Стойностите на тези полета ще бъдат прехвърлени в документа за корекция.

4. Отметки „Сметка и корр. сметка“, „Детайли“, „Ресурси“ и „Чертежи“.
В зависимост от избрания регистър някои от тях може да бъдат скрити.

На раздел "Сметка и кореспондентска сметка" Избран е „Акаунт“ (който ще бъде нулиран). Също така, ако е необходимо, можете да изберете „Кореспондентска сметка“, нейната подсметка, извънбалансови измервания и ресурси. Стойностите на тези полета ще бъдат вмъкнати във всички транзакции до „Кореспондентската сметка“.

На Раздел "Подробности". Можете да изберете стойностите на детайлите, които ще бъдат заменени във всички движения на документа за корекция.

На Раздел "Ресурси". трябва да маркирате тези, които трябва да бъдат нулирани (всички са избрани по подразбиране). Можете например да нулирате само „Суми“, без да променяте „Количество“.

На Раздел "Избори". можете да изберете необходимите условия. Например, ако трябва да нулирате не всички салда, а само тези, които се отнасят до конкретна организация. Или само тези с отрицателни салда.
Когато задавате селекции, можете да изберете вложени полета и групи „И“, „ИЛИ“, „НЕ“.

Всяко поле или регистър може да са недостъпни, ако няма права за тях или са деактивирани в настройките на програмата (функционални опции).

За да разберете кои документи за корекция са „видяни“ в текущата конфигурация, трябва да щракнете върху въпросителния знак вдясно от полето „Документ за корекция“.

Съвместимост

Обработката е предназначена предимно за системи, управлявани от интерфейс. В системи, разработени в стария интерфейс, той също ще работи, но с някои ограничения. Подробности в таблица 1.

Можете да нулирате всички регистри, използвани за извършване на движения в документи за корекция.

Таблица 1. Конфигурации, върху които е тествана обработката

Лечението е предназначено за дебели и слаби клиенти.
Кодът е отворен.

Решихме по някакъв начин да възстановим реда в конфигурацията на UT версия 11. И там ... Салдата на стоките не съвпадат с балансите на организациите (използват се няколко организации), а с пратки стоки те изобщо не са близки и дори комисионната търговия се използва заедно с редовната търговия. Накратко, всичко е толкова занемарено, че е по-лесно да се започне от нулата, НО... Не можете да започнете от нулата - има връзка с корпоративното счетоводство 3.0 (справочници, документи) и там отчетът вече е подаден. Решихме отделно да сложим ред в счетоводството и отделно в счетоводството. Конкретно за UT решихме: нулираме всичко, свързано със стоки (стоки в склада, стоки на организации, пратки със стоки на организации, плюс регистри, свързани с комисионната), след това правим фиктивна разписка (включително за комисионна), и коригираме взаимните разплащания чрез коригиране на взаимните разчети. Първо започнах да пиша обработка за конкретни регистри, докато пишех, мислех да напиша универсален за приблизително същото време, но да е подходящ за всички регистри, за да не се налага да го пренаписвам десет пъти по-късно . Също така трябва да е подходящ за Retail 2, Complex и други конфигурации за управлявани форми. Тестван на UT11.

Как да използвам. Първо, създаваме ръчно празен документ за „корекция на регистъра“, задаваме датата и часа (зададох 23:59:59 в края на тримесечието), балансите в регистъра ще бъдат отведени точно на тази позиция (позиция на документа), в общо взето, от документа ни трябват само позицията и необходимите. След това избираме кои регистри трябва да нулираме и натискаме „Генериране“. Отваряме корекцията, разглеждаме, проверяваме регистрите с помощта на отчети и/или универсален отчет. Салдата са затворени за всички измерения и за всички ресурси. Също така във формуляра има избор по организация и склад (връщане от оригиналната версия, но работи), не добавих други селекции (тъй като изобщо не ми трябваше), който има нужда, може добавете го сами, всичко е ясно написано в модула, а не аз започнах да го използвам, защото например, ако направите избор по организация, тогава за регистъра „Стоки на организации“ изборът ще работи, но за регистъра „ Стоки в складове” няма (няма такова измерване), затова го нулирах без избор.

Мина известно време...

Излезе нова версия, сега обработката се научи (преди това даде грешка - тоест всъщност работеше само с балансови регистри) за обръщане на движенията в циркулиращия натрупващ регистър. Освен това движенията са обратни, т.е. ако погледнете регистъра, да речем „Продажби“ в UT11, тогава след сторниране продажбите изобщо няма да се показват, т.е. сякаш изобщо не е имало продажби - оборотът като цяло за периода ще е празен. Още веднъж - оказва се, например имаме продажби за периода 1-30 януари, на 31-ви правя сторно, след това като погледна справката от 1 до 30 - ще видя продажби, от 31 до 31 - Ще видя обратни движения, от 1- 31 - ще покаже празно. Например, обърнах движенията на „Каса“ в UT11 и Retail 2.2, когато трябваше да подредя „Каса“ (50 сметка, кой знае).

Да, забравих да кажа, появи се полето "Начална дата" - служи за задаване на начална дата на периода за оборотни регистри (за салда, разбира се, не важи), позицията на документа "Корекция на регистъра" се използва като крайна дата на периода (за оборотни регистри) - т.е. както за балансовия регистър (салдата се отстраняват в позицията на документа). За оборотните регистри „Началната дата“ може да остане празна - в този случай тя се възприема като най-ранната дата, която може да съществува, а за оборотния регистър това ще означава, че всички движения от началото на счетоводството до позицията на „ Корекция на регистрите” са сторнирани.

Добра новина - цената в точки е намаляла.

Научете се да работите с регистри (1C: Счетоводство 8.3, издание 3.0)

Уважаеми читатели, в този урок искам да засегна изключително важна тема при работа в 1C: Счетоводство 8.3 - Регистри.

Веднага ще ви покажа с малък пример защо това е толкова важно.

Нека имаме ведомост за заплати за януари:

В началото на февруари създаваме фиш за заплати от касата и натискаме бутона „Попълване“:

И получаваме следното:

Но за януари:

• Начисляване на 50 000 рубли
• Данък върху доходите на физическите лица 6500 рубли
• Общо дължими 43 500 рубли

Къде се прокрадна грешката? Нещо се обърка? Възможно ли е винаги да въвеждате сумата за плащане ръчно сега?

Опитен счетоводител веднага ще направи баланс за сметка 70:

И ще се озадачи още повече, защото според отчета същите 43 500 все още са дължими! И откъде дойдоха допълнителните 5000 рубли?

Освен това такава ситуация (с всякакви изчисления) може да се случи както в „тройката“, така и в „двойката“.

Днес ще се опитам да повдигна завесата на тайната - защо понякога програмата се държи толкова странно. Ще ви кажа как да намерите и коригирате грешката в такива случаи. Към края на статията ще разберем откъде са дошли тези 5000 рубли.

Така че, да тръгваме!

Научете се да виждате регистри

При осчетоводяване на документи 1C:Счетоводство 8 прави записи в счетоводни сметки (бутона DtKt за всеки документ):

Именно на базата на тези транзакции се изграждат всички счетоводни отчети: Анализ на сметката, Сметкова карта, Баланс...

Но има огромен слой данни, които се записват от програмата паралелно с осчетоводяванията и се използват за всичко останало: попълване на KUDIR, книга за покупки и продажби, регламентирана отчетност... дължими заплати, накрая

Както вероятно вече се досещате, този слой се нарича регистри, Ето го:

Сега няма да навлизам в подробности за описанието на самите регистри, за да не ви объркам още повече.

Нека разгледаме по-подробно регистъра „Изплащане на заплати“ – именно той има смисъл за решаване на проблема ни с допълнителните 5000:

Виждаме два записа в този регистър, направени в пристигането, тоест в плюс. Ако превъртим вдясно на екрана, ще видим на първия ред сумата за плащане „-6 500“, а на втория „50 000“.

Салдото в този регистър -6 500 + 50 000 се равнява на 43 500, което трябва да бъде включено в документа „Извлечение за плащане от касата“, когато щракнем върху бутона „Попълване“.

Пак повтарям - платежната ведомост определя просрочените ни заплати към служителя не по сметка 70, а по регистър „Заплати“.

Оказва се, че знаем, че заплатата за изплащане се попълва въз основа на този регистър, но дори и да видим записите в регистъра, не можем да разберем какво не е наред.

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

Да се ​​научим да анализираме регистри

И има такъв инструмент, той се нарича " Универсален отчет".

Отидете в секцията „Отчети“ и изберете „Универсален отчет“:

Изберете тип регистър „Регистър на натрупване“, регистър „Изплащане на заплата“ и щракнете върху бутона „Генериране“:

Оказа се не много информативно:

Това е така, защото е необходима предварителна настройка на отчета, щракнете върху бутона „Покажи настройките“ и в раздела „Групиране“ добавете полето „Служител“:

В раздела „Избори“ правим избор за нашата организация:

Кликнете върху бутона "Генериране":

Сега това е по-интересно. Виждаме, че остатъкът, който трябва да се плати на нашия служител, е същият 48 500 рубли!

Отидете отново в настройките на отчета и добавете ново поле „Рекордер“ към раздела „Индикатори“:

Отново генерираме отчета:

Сега можем ясно да видим, че 5000 се появиха в резултат на операцията (очевидно въвеждане на баланси) на 31 декември 2014 г.

И ние трябва или да променим тази операция, или ръчно да коригираме регистъра „Дължими заплати“ и да затворим тези 5000 рубли, например на 31 декември 2015 г.

Да тръгнем по втория път. И така, нашата задача е да се уверим, че в началото на 2016 г. няма задължение към служителя в регистъра „Заплати“.

Това става чрез ръчна работа.

Научаване на настройка на регистри

Отидете в секцията „Операции“ и изберете „Операции, въведени ръчно“:

Създаваме нова операция в края на 2015 г.:

От менюто "Още" изберете "Избор на регистри...":

Посочете регистъра „Заплата за изплащане“ и щракнете върху OK:

Отидете в раздела за регистрация, който се появява и направете разход от 5000 рубли:

Правейки това, ние като че ли изваждаме 5000 рубли от регистъра на служител, за да стигнем до нула до началото на 2016 г.

Извършваме операцията и регенерираме универсалния отчет:

Всичко се получи! Виждаме, че нашата ръчна операция от 31 декември 2015 г. доведе баланса до нула и дължимата заплата след начисляването е равна на очакваните 43 500.

невероятно. И сега ще проверим това в платежната ведомост.

Но първо искам да обърна внимание на още един важен момент:

Обърнете внимание, че балансите в началото и в края за група „Служител” показват глупости. Това не е грешка, това е нюанс, който трябва да се вземе предвид, свързан с архитектурните характеристики на 1c.

Ако изискваме баланси по групиране на служители, първо трябва да премахнем индикатора „Регистратор“, който добавихме от настройките.