реализованы возвраты, новый интерфейс для дин.кода

[Cromeshnic]

"платежи с отрицательной суммой?"
ага

Мы с 1С так пилили взаимодействие: из 1С возвраты и перенос средств на другой договор (по банковским выпискам) приходят с тем же типом платежа, но отрицательной суммой.
Удобно сверять потом.
Ну или отдельным типом платежа, если 1С-никам так надо (разные типы документов - разные типы платежей).
А тут вроде сверка будет по платежам, но нужно брать конкретно "вот эти 2 расхода".

Я подобным образом сейчас страдаю во всех отчётах по периодическим начислениям: сделал возможность делать пересчёты по каждой услуге отдельно на произвольную сумму (через расходы): добавил 100500 типов расходов и табличку соответствия услуги и расхода.
Теперь в каждом отчёте и выгрузке начислений нужно костылить union или join этих расходов.
Знал бы, сколько гемора будет - сделал бы через RSCM услуги по 1 копейке. БУдет время - мб и переделаю.

Тут то же самое: лучше чтобы платежи были отдельно, расходы (единовременные услуги) - отдельно, периодические начисления (contract_account) 0 - отдельно. Вот в 6+ даже и корректировки визуально вынесли отдельно от расходов.

[Cromeshnic]

Логически не разбирался с возвратами в текущей реализации (другой сотрудник делал), поэтому как лучше сделать - не скажу.
Просто подумайте, мб что-то интересное придумаете.
Например, в конфиге плагина типы платежей помечать как возвраты.
И/или все отрицательные суммы воспринимать как возврат, например.

[Cromeshnic]

Сейчас он вроде ругается, если попытаться внести отрицательную сумму с печатью чека. А можно вместо этого спрашивать "вы хотите сделать возврат"?

[Cromeshnic]

Дописываю щас в отчёт по сверке платежей с 1С:
$this->bbcode_second_pass_code('', '
case 2://платежи
//Из-за того, что возвраты по кассе делаются через расходы, будем клеить их,
// но подставляя Id соответствующих типов платежей - placeholder-ов
// Соответствие Id расхода -> id платежа-placehoslder-а берём из конфига:
// custom.bookkeeping.refund.chargeId2pt.1234=5678
// пишем соответствия в темповую таблицу, затем делаем union расходов с типами из этой таблицы
...
')

[dimOn]

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

[Cromeshnic]

Почему нет? Он даёт добавить (если без печати чека), логика никакая не ломается.
Мы так руками давно взаимозачёты делаем, кстати. И возвраты те же.

И отрицательными расходами пересчёты тоже, кстати.

Вообще, "приход/расход" у нас на самом деле логика не по знаку операции, а по бизнес-логике:
приходы - это операции с живыми деньгами с точки зрения бухгалтерии
расходы - с начислениями за услуги

Т.е. корректировка "денег" (отрицательные платежи) - это возвраты и взаимозачёты
Корректировка "начислений" (отрицательные расходы) - это пересчёты начислений за аварии или некорректные начисления в предыдущих (или в текущем) периодах.
Соответственно и по отчётам деньги к деньгам, а расходы к начислениями должны быть.

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

[Cromeshnic]

Вот например - возврат остатка клиенту после расторжения договора.
Потом при сверке платежей с 1С по Внешторгбанку будет всё красиво.

[Cromeshnic]

Ну даже элементарно - как пользователь потом сверку по кассе будет делать?
Запускать в модуле Reports сначала отчёт по платежам, затем отчёт по расходам?
И так везде придётся делать.

[dimOn]

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

[dimOn]

$this->bbcode_second_pass_quote('Cromeshnic', '�')�у даже элементарно - как пользователь потом сверку по кассе будет делать?
Запускать в модуле Reports сначала отчёт по платежам, затем отчёт по расходам?
И так везде придётся делать.

[Cromeshnic]

$this->bbcode_second_pass_quote('dimOn', '
')ну а тут какое предложение в итоге? если отрицательный приход, то тоже запулять как возврат сразу?

[dimOn]

$this->bbcode_second_pass_quote('', '�')� писал уже: деление на "деньги" и "начисления". Корректировки/возвраты бывают и там и там.

[Cromeshnic]

Ну вот нас сейчас бухгалтерия дрючит аудитами (внешними и внутренними) - всё строго должно быть, данные в 1С совпадать с биллингом.
И если раньше хватало, чтобы балансы сходились, то теперь должно совпадать по услугам и по типам платежей.
Поэтому например расход "Корректировка" превратился в 100500 расходов "Корректировка за ...".
Всё это контролируется специально сделанными в 1С обработками, которые дёргают кучу отчётов биллинга для поклиентных сверок с точностью до услуги.
И в каждом отчёте приходится городить огороды костылей.
Добавлять сюда ещё возвраты по кассе в виде расходов очень не хочется.

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

Поэтому и хочется от биллинга более жёсткой что ли, "бухгалтерской", логики.
Например, нормального закрытого периода
Или чтобы логика возвратов/корректировок нормально "стыковалась" с ожиданиями бухгалтерии, а не только продаж/обслуживания.

[dimOn]

да тут всё понятно, несколько замороченная задача, в общем. пишите в HD, не дороже обращения

[Cromeshnic]

Сделал.
HD: 6873

Кстати, для платежей через конфиг плагина задаётся мэппинг типов платежей на серверы печати.
А для расходов-возвратов есть такое сейчас? Или можно возврат провести любым типом расхода на любом сервере?

[dimOn]

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

[dimOn]

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

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

[Cromeshnic]

Вытащить проверку возможности проведения платежа/возврата?
Можно. Я, кстати, и собирался после доработки делать в динкоде на добавление платежа ограничивать платежи возвраты по типам (чтобы платежи по кассе можно было только с суммами>0, а возвраты - только через отрицательные платежи отдельных типов).
Только тогда в CheckMaker методы проверки должны вызываться до добавления платежа на договор, а методы печати чека - после, верно?

[Cromeshnic]

Про "очередь не в курсе", а выбор, например, так:
1. Дёргаем метод проверки прав. Метод возвращает ок или ошибку, также опционально возвращает Id принтера для печати.
2. Добавляем платёж в BG
3. Если id принтера не указан - спрашиваем. Если указан - печатаем на него.

[dimOn]

$this->bbcode_second_pass_quote('', '�')�олько тогда в CheckMaker методы проверки должны вызываться до добавления платежа на договор, а методы печати чека - после, верно?

[Cromeshnic]

А, я почему-то думал, что id платежа уже есть при печати. Ок.

[dimOn]

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

[Cromeshnic]

Как прогресс? Или dimOn ушёл в отпуск?

[Cromeshnic]

up?