ТиС 9.2. Почему документ-основание не имеет приоритетов по оплате?

Пользователь вводит Строку выписки банка (Расход) на основании приходной накладной. Я по простоте душевной считал, что эта накладная будет оплачиваться первой. Ничего подобного! По фифо оплата документов поставщика идет независимо ни от чего... Это по какой же такой логике, может скажет кто?

Потомушто "документ-основание" не имеет никакого отношению к слову "Основной", "Основа", "Опора" и т.п. в смысле "Начало всему" ;)
Этот термин означает всего-лишь, что при отрытии нового документа существует связь с неким "документом-основанием". Только ссылка в качестве параметра. И только на момент создания. И даже использование реквизитов "основания" надо расписывать самому. И это все. Потом связь теряется навсегда (если где-то не сохранена).
Так что мечтания простой души надо воплощать руками... :))

1. "надо воплощать руками... " - нет проблем, заняло минут 15... Но в голове не укладывается - почему пользователям типовой не представлена возможность тем или иным способом выбирать документ поставщика, который они хотят оплатить в первую очередь...

(2) Потому что сильно умные юзвери, мнящие себя "умнее" 1С (типа я тупую работу могу сделать лучше 1эсины) через пару дней все забывают и на оплаченную накладную вешают еще одну оплату или забывают "привязать" докоснование или умудряются привязать в качестве дока основания накладную с другим договором или ваще другого клиента, потом бегут к программеру с предложением к авансовому платежу от 15 числа с.м. в качестве основания "привязать" накладную от 25 числа с.м.
...продолжать?

(2) Как отработает твой алгоритм если потом по оплаченной накладной будет "возврат от покупателя"..? куда положишь образовавшийся "аванс" покупателя?

есть 2 отгрузки на 100 и 200 руб, к ним соответсвенно "привязаны" оплаты соответсвенно
вариант 1: 90 и 200 руб
вариант 2: 110 и 200 руб
вариант 2: 110 и 190 руб

и т.д.
отмазки в виде "у нас привязываются всегда один к однму" не принимаются...

(3-5) Если (2) сделал первый шаг, он будет вынужден сделать все остальные - т.е. управлять всеми движениями по регистру взаиморасчетов.
Вполне реально и имеет конкретный смысл.

(5) Обычно говорят так: "У нас всегда оплата один к одному, полностью. Ну, бывает иногда, но это редко. Да, некоторые вперед платят, с "запасом", но это не все..."
 
Действительно, чего там... Ну не будет операция работать в 5% случаев...
Одна операция... А две уже в 10%... А четыре уже в 20%...
А сколько, говорите, операций у нас?

3. Видишь ли, если в "ТаблицеИтогов" (глобальный модуль, глДвижениеДолгов) документа, указанного в качестве основания не окажется, то сработает типовой алгоритм))
4. О каком "возврате покупателя" ты спрашиваешь, если речь едет об "оплате поставщику"? А если речь идет о возврате поставщику, то он закроет документ(или часть) поставщика по фифо или станет долгом поставщику, если неоплаченных документов нет.

7. "Лишние" суммы закроются по фифо, не переживайте...

3, 7. Т.е. своим заказчикам вы в ответ на просьбу о том, чтобы была возможность выборочной оплаты отвечаете что-то типа "1С лучше знает, как надо платить", да?))

(6) Была и у меня идея (2). По размышлению - да, хорошо бы сделать, чтоб в первую "очередь" погашался привязанный документ... но если (3-5) - все съедет, причем юзер будет глубоко уверен что все ложится как надо... потом придется переписать все отчеты по взаимрасчетам - чтоб итоги по привязкам считались, а чтоб привязки правильно обсчитать (в случае частичных оплат, например) - придется обсчитывать привязки начиная с самого первого дока по этому клиенту - итого - тот же учет взаимрасчетов, что и на регистрах + писаный одним человеком + куча косяков - оно нам надо...?
М.Б. (2) и (0) лучше под "реализацию привязок", когда нужно проконтролировать чтоб оплата ложилась именно на опред.документ - выделить под этот док отдельный договор? Только обычно выясняется что проплату надо положить на четкий документ - уже постфактум, а не в момент отгрузки, которую надо проконтролировать...
Итого: на фирме система учета взаиморасчетов с клиентами не продумана...
Вот только часа 3 назад - полтора часа читал ликбез по телефону на эту тему - зп манагеров зависит от того какой документ 9товар) оплачивается - считают по привязкам доков, при этом ясен пень никакой правде не соответсвует, потому как прога считает по другому потому как в первой же отгрузке привязку сделали но сумму ошибочно на 800 руб меньше поставили и пошло...

(8)
3. Видишь ли, если в "ТаблицеИтогов" (глобальный модуль, глДвижениеДолгов) документа, указанного в качестве основания не окажется, то сработает типовой алгоритм))
//
ага, и следующий раз чтоб сделать правильную привязку - придется каждый раз отчет "ведомотсь по контрагентам" смотреть...?
(9) 7. "Лишние" суммы закроются по фифо, не переживайте...
ага...- и смотри мой предыдущий абзац...
Итого - мож. все таки вести учет взаиморасчетов "по договору"
все эти и...ы нужны только для того, чтобы "кому-то" было удобно.
А когда выясняется при сверке что начальное сальдо и конечное бъется - никому нет никакого дела как легли взаиморасчеты "внутри" договора - сощлись они по докам или нет... Правда книга покупок/продаж может немного "окосеть", но рез-т в итоге все равно будет праивльный - не в этом месяце так в следующем...
В итоге: бухия ведет свой учет, ТИС - свой и живут два одиночества совершенно самостоятельно... и бухия вместо того, чтобы налоги минимизировать, отчеты не в последний день считать, законодательство читать и прочее - привязки делает, потом пытается понять откуда итоги правильные взять - из привязок? из отчетов? напрягает программера... вся котнора на ушах и наконец... приходит понимание как надо было делать с самого начала... что 98% клиентов устраивают взаиморасчеты "по договору", особенно когда в месяц с ним не 2-3 дока а 200-300 доков и больше... а для оставшихся 5% - на каждую сделку отдельный договор - это легче запрограммить чем весь учет переписывать...
все. я для себя эту тему закрыл.
А по покупателям/постащикам - сорри, лажануляс, да и то - ситуевина будет точно такая же...

(10) 3, 7. Т.е. своим заказчикам вы в ответ на просьбу о том, чтобы была возможность выборочной оплаты отвечаете что-то типа "1С лучше знает, как надо платить", да?))
Нэт, дарагой! Не так отвэчаэм! Отвечаем - надо будэт вам выборочная оплата - а как я ее сделаю (1С, руками, на счетах, на Галактике) - не клиента дело.
Только ты начнешь программить на 1000000 мильенов строк кода, а я выборочные оплаты реализую вообще без программинга...

12. "ага, и следующий раз чтоб сделать правильную привязку - придется каждый раз отчет "ведомотсь по контрагентам" смотреть" - нет, не придется. Я уже написал в 8.3., что будет, если в качестве документа-основания ошибочно введут документ, который уже оплачен.
13. Если клиент отдает тебе учет в аутсорсинг, то подход справедливый. Но у меня иные ситуации и вариант "не клиента дело" в них не проходит.

(14) Или я чего-то не понимаю или бляха/муха! ;-)
1. Да, сработает типовой алгоритм.
2. Пришла выписка. платеж по накладной №№ сумма в сумму, привязываем - хрен ли привязывать, если по п.1 накладная NN уже оплачена на 30%...?

15. Привяжется не сумма документа-основания, а сумма долга по регистру Взаиморасчеты, ну что непонятного-то?

(14) 13. А при чем здесь аутсорсинг? Меня с клиентом связывают обязательства поставки товара и приема оплат от него. И какое дело клиента на чем у меня на фирме, к которой он не имеет никакого отношения, ведется учет и как я буду отражать его платежи/отгрузки? Он желает получить инфу какой платежеом он закрыл какой документ - он ее получит! Причем если он написал что в счет оплаты конкретной накладной - я закрою эту накладную (если это было обговорено заранее во время отгрузки! а если это не было обговорено заранее - манагер у меня выслушает лекцию с экскурсом в историю, ласковым кунанием лицом в грязь, и не он один а все манагеры будут сидеть и слушать урок с разжовыванием, сниманием памперсов, вставлянием ежиков в попу и показом всякого другого ;-) - и гендир меня поддержит - и следующий раз с клиентом он это обговорит в момент сделки) и клиент будет полностью удовлетворен и все будет так как надо ему и мне и все это - см.13

Излишек суммы закроет другой документ по принципу фифо (типолвой вариант)...

(16) Да не, все понятно.
Только выше речь шла про то, что при проведении оплаты в первую очередь погашать привязанный кредитный док - а какой смысл привязывать, если невзирая на привязку погашаться все равно будет по долгам регистра?
Может тогда вообще не морочится с программированием приоритетного зачета привязанного дока? Допустим, ничего не меняли в типовом алгоритме - указали док в привязке - успешно погасился - ура. "Неуспешно" погасился, например, вследствие см.15.2 - и такое нас тоже устроило...
Итого - как погасится, так и погасится - устраивает нас в любоим случае - чего программить то?

Я дико извиняюсь - ты кто на фирме? Программист? Если да, то почему ты занимаешься закрытием накладных? Программист ИМХО должен делать инструмент, пользоваться этим инструментом должны другие... Конечно, если у программиста нет цели "привязать" фирму к своей персоне)))

(18) Кардинальная ашипка - юзеру создается иллюзия что погашение долгов осуществляется по привязкам - ведь такая возможность запрограмлена - и он ориентируется на эту возможность, а на самом деле - как погашалось по типовому алгоритму, так и погашается... и чтоб узнать как все-таки погасился документ - по привязке полностью или по типовому алгоритму - придется смотреть типовой отчет - итого имеем одно лишнее телодвижение юзера с потенциальным привнесением элемента двусмысленности в обычную рработу - если до этого он на привязки не смотрел, то теперь смотрит - а результат тот же...
Жалко, что юзеру в начале работы никто не объяснил (начальство денего зажало на обучение, видать ;-) что ввод на основании используется ТОЛЬКО ДЛЯ !!_ОБЛЕГЧЕНИЯ ЗАПОЛНЕНИЯ ДОКУМЕНТОВ_!! ПО ПРИНЦИПУ "ОДИН РАЗ СУММУ ВВЕЛ - ДАЛЬШЕ ПЕРЕНОСИТСЯ АТОМАТОМ" и В ОБЩЕМ СЛУЧАЕ никакого отношения к отражению дока-основания в учете текущего дока не имеет...

Можно много говорить на эту тему))) Но зачем? Моего заказчика не устраивает отсутствие возможности гасить документы выборочно... прав он или нет - это вопрос другой... о всех рисках, связанных с таким погашением я ему сообщю...

21. Зачем типовой отчет? Движения документа, это заметно быстрее...

(2) Я тож дико извиняюсь если из моих постов сложилось мнение что Я лично занимаюсь закрытием накладных - сорри, под "Я" в моих постах понимается - моя фирма, коллектив манагеров, руководстов и я личной персоной. И, поверь, на фирме достаточно достаточно (каламбур) действительно интересных для меня лично и для фирмы задач и задача, описанная в (0) - это одно из самых последних дел которые я стал бы программить ибо эта задача решается штатными средствами без программинга (см.пост 13 посл.абзац).
И последнее - без ложной скромности - ибо скромность украшает только того, у кого других украшений нет - все люди и фирмы были очень рады моим урокам - именно урокам не побоимся этого слова - по эффективному использованию штатных средств и прежде чем давать эти уроки - еще до них я хожу и смотрю что где как и почему на фирме делается... и передают меня из рук в руки и поэтому когда я прихожу к клиенту - он РАДОСТНО бежит греть мне чай и заказывать обед - именно потому что в мое ОТСУТСТВИЕ все вертится и работает...
Хотя и я лажаюсь регулярно... ;-) как и все...

(23) несомненно... только из типовых движений дока хитрый манагер может извлечь кучу не полагающейся ему инфы ;-) а в отчете уведит только что ему надо... ;-)
(22) Как ты справедливо заметил, итогом всего этого длинного флейма является "о всех рисках, связанных с таким погашением я ему сообщю..."
Рад что мы пришли к консенсусу, потому как привнесение возможности (0) не уменьшает "риски", которых в ТИС и так достаточно, а увеличивает... ;-)

25. увеличивает, не спорю... как любое увеличение "гибкости"...

(26) Это да...
И вот будут манагеры эту гибкость гнуть в любую сторону, а тебе потом "накладные закрывать придется"... ;-) вместо прогрессивного программинга ;-)
Спок ночи!

Знаешь, на меня где сядешь, там и слезешь))) Особенно в тех вопросах, где я предупреждал, а заказчик выбрал более рисковый вариант. Так что вряд ли...
И тебе приятных снов...