задвоение номеров ГК

[anny]

Скажите, кто сталкивался с проблемой задвоения номеров ГК?

Есть AX 3.0, SP 3, без hotfix-ов.

При разноске журналов основных средств, номера попадают в numberSequenceList, статус Активный, мероприятие - нерешенный. Потом эти номера преобразуются в статус - Свободно, мероприятие - не используется.

Соответственно, затем эти номера снова выбираются, хотя уже существуют проводки с этим номеровм в LedgerTrans, и происходит задвоение.

Серия документов - непрерывная, стоит автоочистка.
Параметры ГК - Запрещать дубликаты, контроль непрерывности.

Подскажите, пожалуйста, что можно сделать? Еще лучше, где поправить.

Конечно, можно убрать непрерывность серии документов, как уже писалось на форуме, но ... должно же работать корректно )


Спасибо

[BOAL]

И это не только в ОС... это и обычный журнал ГК и касса этим грешат...

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

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

[anny]

Спасибо, за участие.

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

И это очередная криво работающая функциональность Microsoft... (

Интересно, кто-нибудь считал соотнесение времени, которое тратится на настройку, доработку функционала, т.е. то, что необходимо клиентам, и на исправление ошибок microsoft в Axapta?

[mazzy]

Цитата:

Изначально опубликовано anny
Получается, что непрерывность без крайней необходимости лучше не использовать.

И это очередная криво работающая функциональность Microsoft... (

Интересно, кто-нибудь считал соотнесение времени, которое тратится на настройку, доработку функционала, т.е. то, что необходимо клиентам, и на исправление ошибок microsoft в Axapta?

Привет, Аня.
Рад тебя видеть.

Нет так маленько.
1. непрерывность действительно лучше не использовать
2. но не потому что это криво работающая функциональность.
3. непрерывность требует существенно больших ресурсов от Аксапты и СКЛ
4. непрерывность надо уметь использовать программисту. Программист должен о многом помнить, чтобы корректно работать с непрерывностью.

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

[Тимур]

А в какой момент у Вас установлено генерировать номер ГК?

[anny]

Я немного посмотрела в коде - на мой взгляд, суть не в том, в какой момент генерируются номера, а в том, что при работе журнала ОС, по сравнению с общим журналом ГК номера точно так же попадают в таблицу NumberSequenceList при создании записей в журнале, но если после разноски общего журнала использованные номера удаляются из этой таблицы, то после разноски журнала ОС они остаются. Следующая по времени процедура очистки переводит эти номера в статус - Свободно. Создаем любой журнал, использующий данную серию.. и получаем сюрпризы...

Решение без программирования - отказаться от непрерывности и/или отключить очистку.

Интереснее было бы в нужном месте вызвать удаление уже разнесенных voucher из NumberSequenceList. Но, увы, я не нашла это место... Вернее подходящих мест слишком много...


to mazzy - спасибо за добрые слова, но я думаю, что имелась в виду другая Аня , еще раз - спасибо.

[mazzy]

Цитата:

Изначально опубликовано anny
Я немного посмотрела в коде - на мой взгляд, суть не в том, в какой момент генерируются номера, а в том, что при работе журнала ОС, по сравнению с общим журналом ГК номера точно так же попадают в таблицу NumberSequenceList при создании записей в журнале, но если после разноски общего журнала использованные номера удаляются из этой таблицы, то после разноски журнала ОС они остаются.

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

Цитата:

Изначально опубликовано anny
to mazzy - спасибо за добрые слова, но я думаю, что имелась в виду другая Аня , еще раз - спасибо.

Извините, обознатушки.
Тогда привет Той Ане

[George Nordic]

Господа!

Попробуйте сделать так:
РК - Платежи - Новый платеж
Введем просто 3 пустые строчки (3 раза Ctrl + N)
Смотрим на номера ГК  - они ОДИНАКОВЫЕ!
Потом прописываем клиентов - (Разных!)и разносим..
с ГК идут проводки с ОДИНАКОВЫМ номером.
Во как. Это бага или фича такая?

С Уважением,
Георгий.

[Maximin]

Смое прикольное - что эта шняга там болтается, по видимому, уже давно, еще с 2.5...
By design - это не глюк, это фича. ))

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

[Maxim Gorbunov]

В общем, это действительно так By Design

Все время возвращать true из takeNewVoucher() я бы не стал.

Лучше сделать так:
1. Во время create() в LedgerJournalTrans_ds сделать forceWrite(true), чтобы пустые записи не плодились, а записывались все время.
2. В validateWrite() сделать проверку, чтобы пользователь не мог создавать строки журнала с пустым AccountNum.
3. Для красоты можно еще выставить свойство Mandatory для AccountNum в форме LedgerJournalTransCustPaym.

[Maximin]

Ну, если реализовать п.2, то п.1 уже, в принципе, и не нужен.

[Maxim Gorbunov]

А вот и нет.
Если не сделать п.1, то записи не будут отправлены в базу данных после нажатия Ctrl+N еще раз. Соответственно не будет вызываться и validateWrite(). Попробуйте

[Maximin]

Ладно, уболтал. )

Еще вот что смущает - (точнее, не еще, а, собственно, одна из причин проблемы)

if (!oldAccountNum && oldVoucher)
return false;

Для чего-то это, может быть, и нужно.....

[anny]

Это не баг, это фича и удобная
Например, если надо перекинуть задоженность по клиенту из краткосрочной в долгосрочную, или рисовать проводки по векселям. В одной строке система не даст сделать проводку, если счет и корсчет совпадают. А если сделать многострочную проводку, документ ГК будет одинаковый, счет и корсчет одинаковые, а профили разноски - разные.

[Maximin]

Короче, сделали так: добавили параметр в настройки журнала, если он стоит в положении "Всегда новый" - ставится всегда новый ГК (всегда takeNewVoucher - true). Иначе - работает, как в стандарте.

[kvan]

2 Maximin:

Цитата:

Смое прикольное - что эта шняга там болтается, по видимому, уже давно, еще с 2.5...

это ты случаем не в том приложении подсмотрел о каком я подумал?
если в том - так там и решение этой фичи было

[George Nordic]

Не, заново напоролись на старые грабли.

Хотя слова Ани заставили нас задуматься

С Уважением,
Георгий.

[kvan]

Аня права
Но в свое время решал эту проблему пунктами 2 и 3 описанными Максимом Горбуновым так как такой функциональности нам тогда не нужно было.