Возможные особенности при создании проводок ГК в УЗ

Автор Сообщение
Jugulator
Главный форумщик

Зарегистрирован: 08.10.2004
Сообщения: 428

Добавлено: 22.11.2009 00:58 Заголовок сообщения: Возможные особенности при создании проводок ГК в УЗ
При создании процедур сверки складских проводок необходимо также учитывать, что возможна не только обычная схема создания проводок "одна строка в SC07 -> две строки в SC25/SCGL (Дт/Кт) -> строки в ГК в зависимости от параметра сжатия проводок".
Может быть проведен ввод дополнительных строк в режиме редактирования проводки ГК перед обновлением складского журнала проводок ГК, либо строки созданы какой-либо процедурой в SC25, например, у нас бывает не 2, а 3-4 строки проводки в SC25 для каждой строки в SC07. В iScala 2.2 SR2 при выводе складских проводок через меню Главная Книга -> План счетов/Запросы -> Запросы по ГК -> Запрос по Строкам Проводки, на форме в поле "Показать складские проводки" — Да, режим печати (П вместо Э), в этом отчете в нашем случае строки могут быть показаны, например, 3 раза подряд вместо одного с одинаковыми количествами и суммами. Так что в своих программах следует этот момент учесть.
aav
Администратор
Администратор

Зарегистрирован: 14.09.2004
Сообщения: 1081
Откуда: Санкт-Петербург

Добавлено: 28.11.2009 12:04 Заголовок сообщения: Re: Возможные особенности при создании проводок ГК в УЗ
Извиняюсь, что долго не отвечал…
Мне кажется, что добавление 3-4 и т.д. строк следовало бы запретить. Разумеется, раз Скала позволяет это делать, значит, вроде бы "без проблем", однако сама логика работы подразумевает тот факт, что одной проводке SC07 соответствует 2 проводки SC25/SCGL. Конечно, раз кто-то так делает, значит есть какие-то причины, но с практической точки зрения мне трудно представить, как это пользователь входит в проводку, коих может быть несколько тысяч или десятков тысяч в день, и добавляет строки. Скорее, это делает какая-то "внешняя" процедура (если это делает VBA проект, это не делает его менее "внешним"), а это, по сути, уже вмешательство в стандартную функциональность… Но то, что раз это возможно, это надо проверять, я абсолютно согласен с тобой, спасибо, за комментарий, постараюсь это учесть.
Jugulator
Главный форумщик

Зарегистрирован: 08.10.2004
Сообщения: 428

Добавлено: 28.11.2009 16:06 Заголовок сообщения:
Запрещать создание более двух строк проводок в ГК из проводки на складе как раз не нужно, потому что это дает определенную гибкость в некоторых случаях, пусть и весьма специфических, как это происходит у нас. Естественно, сама сумма складской проводки ни в каком случае не должна изменяться, и даже должна быть отражена на одном счете, но вот субсчета в его составе могут быть использованы разные, на них и разбивается общая сумма. Нам это потребовалось для "западного" учета в связи с требованием разделять затраты на произведенную и закупленную продукцию по источнику их возникновения: собственно внутри компании и на услуги внешних организаций, причем именно на разных субсчетах. Когда приходит сырье, закупка происходит внутри компании, а дополнительные затраты считаются внешними, в этом случае для ГК создается по две строки проводки из каждой складской, как обычно. Далее, уже при перемещении в производство на другой склад для каждой партии стоимость разбивается на два субсчета. В производственном заказе некоторые виды затрат считаются внутренними, часть внешними, и готовая продукция перемещается на торговый склад для продажи с учетом этого разделения. На торговом складе есть также просто закупленная продукция, но затраты на нее также пришли "снаружи". Изменение проводок в SC25 позволяет не заботиться об их дальнейшей судьбе, потому что iScala сохранит их правильно в истории SCGL и запишет в ГК сжатыми или нет, но тоже правильно, по консолидации они придут в другую компанию и ОК.
aav
Администратор
Администратор

Зарегистрирован: 14.09.2004
Сообщения: 1081
Откуда: Санкт-Петербург

Добавлено: 28.11.2009 18:32 Заголовок сообщения: Запрещать или не запрещать?
Разумеется, вам на месте виднее, но всё равно при этом не приходится говорить о стандартной функциональности. Это некое очень важное, но всё же усовершенствование. Что касается самих требований бизнеса, они понятны, более того, и в российском законодательстве встречаются подобные коллизии (тот кто это придумал, разумеется, полный идиот, но требования тем не менее часто действуют), когда с точки зрения бухгалтерского учёта некоторые затраты могут быть включены в себестоимость, а с точки зрения налогового… !@#$%^&*