powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / [игнор отключен] [закрыт для гостей] / ВводНачальныхОстатков 62.0х АП Баг?
9 сообщений из 9, страница 1 из 1
ВводНачальныхОстатков 62.0х АП Баг?
    #35846304
1chainik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Господа, поясните:
Бухгалтера хотят иметь субсчет 62.0х активно-пассивный. Заводят. Далее лезем в документ
ВводНачальныхОстатков.
Раздел учета - 62. (если не править руками макет СписокСчетовРазделовУчета).
При этом руками можно вводить только дебетовый остаток (поле СуммаКт не доступно для ручного ввода). (Или, соответсвенно кредитовый - если субсчет либо только А либо только П). То что не дает оба поля на "АП" - баг?

Пока переносил им остатки автоматом (писал себе в поле СуммаКТ не доступное в ручном режиме) - это никого не волновало. Но теперь они хотят править документ ВводНачальныхОстатков руками. Для того, чтобы они могли бить кредитвоые суммы - пока не нашел ничего, кроме как исправить Макет "СписокСчетовРазделовУчета" (добавить исключения в 62 нруппу и счет в "остальные счета"). Т.е., де-факто, расковырять конфигурацию. А это (необходимсоть ковырять конфигурацию при банальном вводе субсчета), мне кажется, баг. Нет?

Есть ли иные мнения, или способы порешить проблему?
...
Рейтинг: 0 / 0
ВводНачальныхОстатков 62.0х АП Баг?
    #35846366
Господин ПЖ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ввести сумму с минусом - не судьба?
...
Рейтинг: 0 / 0
ВводНачальныхОстатков 62.0х АП Баг?
    #35846378
1chainik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Господин ПЖввести сумму с минусом - не судьба? это только г-н ПЖ не отличает "сторно дебета" от (нормального) кредита?


таки не судьба.
...
Рейтинг: 0 / 0
ВводНачальныхОстатков 62.0х АП Баг?
    #35846398
Господин ПЖ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
отличаю. И сторно тут не причем. Просто в форме ввода остатков доступна одна только половина проводки, т.к. вторая идет на "00". Когда вводишь -10 рублей, то сальдо корректно отображается на Кт без минуса (на форме ввода остатков). А проводку лепит все равно на 62.Х 00 на -10. Косяк похоже.
...
Рейтинг: 0 / 0
ВводНачальныхОстатков 62.0х АП Баг?
    #35846525
1chainik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
когда субсчет или только активный или только пассивный, то доступное поле формы "Сумма" разносится в нужную сторону (Дт или соотв. КТ), в соответсвии с планом счетов.

При АП (активно-пассивном) субсчете однозначно все из поля Сумма попадает в дебетовую сумму. Не зависимо от знака. (т.е. имеем отрицательный (сторнирующий) дебетовый остаток, вместо нормального кредитового). Это я проверил первым делом. "По-большому" - для АП нужно бы давать или оба поля, или давать в руки пользователя модификатор типа суммы (какой-нито крыжик Дт/Кт).

Поэтому для меня выход - перенести субсчет в группу "Прочие Счета БУ" - для него выдает оба поля (остатокДт, ОстатокКт). Но этот выход - правка конфы со всеми сопутствующими неприятностями (вечное отслеживание при накате обновлений). Чего бы не хотелось.



ЗЫ : Но вот читаем битым текстом (Процедура УстановитьВидимостьКолонок()):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
	ИначеЕсли РазделУчета = Перечисления.РазделыУчетаДляВводаОстатков.РасчетыСПоставщикамиИПодрядчиками Тогда
		ТекущийСписокКолонок = ЭлементыФормы.РасчетыСКонтрагентами.Колонки;
		
		ТекущийСписокКолонок.Сумма.ТекстШапки				   = "Сумма";
		
		ТекущийСписокКолонок.ДоходЕНВД.Видимость          = Ложь;
		ТекущийСписокКолонок.ДоходКомитента.Видимость     = Ложь;
		ТекущийСписокКолонок.СуммаКт.Видимость            = Ложь;
таки обидно, да.

в сопоставлении с
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
	ИначеЕсли РазделУчета = Перечисления.РазделыУчетаДляВводаОстатков.РасчетыСПрочимиДебиторамиИКредиторами Тогда
		ТекущийСписокКолонок = ЭлементыФормы.РасчетыСКонтрагентами.Колонки;
		
		ТекущийСписокКолонок.Сумма.ТекстШапки				   = "Остаток по дебету";
		
		ТекущийСписокКолонок.ДоходЕНВД.Видимость		  = УСН_ДР;
		ТекущийСписокКолонок.ДоходКомитента.Видимость	  = УСН_ДР;
		ТекущийСписокКолонок.СуммаКт.Видимость			  = Истина;
или
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
	ИначеЕсли РазделУчета = Перечисления.РазделыУчетаДляВводаОстатков.ПрочиеСчетаБухгалтерскогоУчета Тогда
		ТекущийСписокКолонок = ЭлементыФормы.БухСправка.Колонки;
		
		ТекущийСписокКолонок.СуммаНУ.Видимость			= ОСН;
		ТекущийСписокКолонок.СуммаВР.Видимость			= ПрименениеПБУ18;
		ТекущийСписокКолонок.СуммаПР.Видимость			= ПрименениеПБУ18;
		ТекущийСписокКолонок.Количество.Видимость		= Истина;
		ТекущийСписокКолонок.Валюта.Видимость			= Истина;
		ТекущийСписокКолонок.ВалютнаяСумма.Видимость	= Истина;
		ТекущийСписокКолонок.Сумма.Видимость			= Истина;
		ТекущийСписокКолонок.СуммаКт.Видимость			= Истина;
		ТекущийСписокКолонок.Сумма.ТекстШапки			= "Остаток по дебету";
		ТекущийСписокКолонок.СуммаКт.ТекстШапки			= "Остаток по кредиту";
кажется таки придется править рабочую конфу (макет). %(
...
Рейтинг: 0 / 0
ВводНачальныхОстатков 62.0х АП Баг?
    #35846935
Сисой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Все начинается со слов: "Бухгалтера хотят иметь субсчет 62.0х активно-пассивный".
И поэтому мы будем тратить силы и средства, создавать несовместимую с типовой конфигурацию.
Ругая автора документа ввода остатков.
А истинная причина, по моему, кроется в том, что методологи типовых 1С совершили грубейшую ошибку при переходе на новый план счетов.
Не сделав счета 60, 62 трехуровневыми.
Если бы объединили 62.01 и 62.02 в одну группу, а 62.21 и 62.22 в другую и т.п., никакого желания вводить АП субсчета не возникло бы.
...
Рейтинг: 0 / 0
ВводНачальныхОстатков 62.0х АП Баг?
    #35847322
VoditelKobyly
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
А я думал, что я один только с этим мучаюсь и своих бухгалтеров к букварю отправляю, а оказывается это "родные" 1с-цы виноваты.
...
Рейтинг: 0 / 0
ВводНачальныхОстатков 62.0х АП Баг?
    #35847694
1chainik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
СисойВсе начинается со слов: "Бухгалтера хотят иметь субсчет 62.0х активно-пассивный".
И поэтому мы будем тратить силы и средства, создавать несовместимую с типовой конфигурацию.
Ругая автора документа ввода остатков.ничего не понял.

Бухгалтера не правы? ну так - вот такие они мерзавцы - удобно им вести что-то на выделенном АП субсчете - они и ведут.

СисойА истинная причина, по моему, кроется в том, что методологи типовых 1С совершили грубейшую ошибку при переходе на новый план счетов.
Не сделав счета 60, 62 трехуровневыми.
Если бы объединили 62.01 и 62.02 в одну группу, а 62.21 и 62.22 в другую и т.п., никакого желания вводить АП субсчета не возникло бы.истинная причина таки в том, что "программирование" конфигураций не должно явно ссылаться на значения данных. А там где ссылается (например НДС как перечисление, а не справочник - см. пример от Naf) - там поздно пить боржоми.

я вот пока обговорил - вроде как бухи обойдутся без ручной правки. Т.е. не будем "делать несовместимую с типовой", оставим "как было". Спасибо, конфигурация хоть и отругивается на пустое поле "Сумма", но при заполненном "СуммаКт" и 0!!!(и только 0) в "Сумма" проводки делает как надо- по Кт. Т.ч заполню пока все внешней обработкой... В крайнем - напишу внешнюю же для правки скрытого поля. А там посмотрим - то ли ишах сдохнет, то ли падишак.
...
Рейтинг: 0 / 0
ВводНачальныхОстатков 62.0х АП Баг?
    #35847757
1chainik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PS имел в виду вот этот пример от Naf:
За это нужно убивать
...
Рейтинг: 0 / 0
9 сообщений из 9, страница 1 из 1
Форумы / [игнор отключен] [закрыт для гостей] / ВводНачальныхОстатков 62.0х АП Баг?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]