Привет!

Господа, одна из ошибок на спеце по платформе: "Не реализована возможность корректного перепроведения документов задним числом". Как реализовать такую возможность?

рауз?

Не проверять остатки,
Не делать движения по партиям

(2) чойта не проверять остатки? проверять но на "щас"

(2) (3) то есть проверять остатки на МоментВремени() вот так:
запрос.установитьпараметр("моментвремени", ?(режимпроведения = режимпроведениядокумента.оперативный, неопределено, моментвремени())) ???

(0) в типовой при проведении задним числом остатки не проверяются, но потом надо восстанавливать партии.
В РАУЗ по-другому, но тоже гемора хватает.

(0) надо сделать как-то так, чтобы при перпроведении задним числом ни чего не ломалось, регистры закрывались и данные учета не искажались

что кроме остатков может сломаться?

(7) себестоимость, например

(8) ну это просто. надо всего лишь сделать отдельный документ расчета себестоимости )))

(8) ну это остатки фактически

(10) в регистрах оборотов тоже легко напортачить

Еще, если блокировки не накладывать, то проведение задним числом (да и передним тоже) даст некорректные движения

(12) передним? да месье знает толк в извращениях!

(13) ты довольно неуклюже остришь тупым концом

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

а если работодатель требует, чтобы была запрещенна возможность проведения задним числом?

(16) ты сабж читал вообще?

(14) а ну ка заостри? в каких случаях надо проведение передним числом? (зы каждый читает мой пост в меру своих испорченностей, несмотря на то, что в (13) было на полном серьезе)

(18) а вот оно чо - для тебя "переднее число" - это "будущей датой". Я имел в виду "оперативное проведение"

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

(19) вот именно )

(20) и чего? в снеговике вроде нет запрета если док одной датой а движения - другой...?

(20) кто вступит в силу через месяц?

блин, ребьзя, вы читаете ветку вообще? Один про фому. дргоуй про ерёму...

(23) через месяц фирма объявляет акцию на определенные договора: платеж клиента, заплатившиго по договорам 1,5,8 в период с ... по ... будет приниматься по курсу 20, а все остальные по курсу ЦБ.

(20) и что мешает? проводи в валюте а в отчетах пересчитывай на дату согласно условий договора

(24) да читаем. только толкование двоякое. а поскольку тс не стал конкретизировать, то мы тут решили пофапать(зачеркнуто) пофантазировать

ВалераОшкин явно пытается нам что-то сказать...

(26) гениальнее в Период регистра сведений писать дату документа. Документ прыгает в будущую дату, а срез последних покажет нужный курс тогда, когда эта дата наступит.

(28) очередную уйню имхо поскольку умного я от него не слышал

(29) вопрос как это сделать В ТИПОВЫХ? или как это сделать вообще?

(30) ты в зеркало давно смотрелся?

(29) какая прелесть. только в одинцэ не ходи работать ладно? там своих копрокодеров вагон

(33) приведешь пример кода, которым гордишься?

(32) только что. морда злая, небритая и хочет комунить уи пать

(34) я кодом не горжусь. я им деньги зарабатываю.

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

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

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

(36) тогда не звизди про копрокод

(38) ты сделай (29) а потом удивись результату. а потом сам тут звезди. очередной г1с?

(39) сделано уже давно и все корректно работает

(40) сочувствую твоим юзерам

(41) ты прикидываешься чтобы потролить или реально такой?

+(41) Что плохого в том, что в регистр сведений будут писаться данные по Периоду, в котором будущая дата?
И что плохого в том, если Период при этом будет равен Дате документа?

(43) все плохо. юзеры смогут спулить твой товар в промежуток между "щас" и "период"

(44) ты товар учитываешь на регистрах сведений? Я фигею....

каким боком твой вы сер относится к (0) ?

(44) Мне, кстати, как раз и надо, чтобы в промежутках между  "щас" и "период" было так, как у тебя с товаром.

(46) Хочешь сказать, что ты испражняешься бабочками?

жесть жестяная. ничему людей жизнь не учит

(49) расскажи, чему тебя жизнь научила?

(50) только одному - оперативный учет наше все. остальное от лукавого.

(51) далеко не все задачи учета можно решить на оперативном учете, который отвечает требованиям в (0)

(52) мы тут черные схемы не рассматриваем. я вообще противник этого хамна. и стараюсь не вляпываться в конторы где jопят заплатить лишние 300 тыщщ налога, зато держат штат копрокодеров на 500

(53) белый и черный учет тут совершенно не при чем

(53) пример тебе к размышлению:
- в БД фиксируются платежи от покупателей. Оператор при вводе платежа может ошибиться.

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


Реализуй мне схему, полноценно работающую по принципу (0).

скучно тут у вас. Перенесли б вы свою фалометрию в почту что ли. Ей богу срамота одна и разочарование

(56) дай молодому франчу повыпендриваться какой он крутой

(57) нашел молодого франча... я еще 7.5 помню

(58) 2.0 вспомнишь - заходи.

(59) так долго не живут

эх молодежь...