Повторное использование номеров документов ГК

[dirigente]

в строках журнала платежей клиентов.

У нас постоянно происходит задвоение (точнее, множественное повторение) номеров документа ГК при использовании Журнала платежей - строки (Клиенты).
Номерная серия непрерывная с очисткой 24 часа + пробовали "толкать" очистку.
Контроль номеров документов в параметрах ГК установлен "Предупреждать в случае повторений". Таким образом, Ax постоянно предупреждает о дублировании номеров.
Система продолжает упорно выделять уже использованные номера документов ГК из различных журналов платежей для новых строк.
Серии документов в процессе эксплуатации не меняли.
Свойство "Изменение номера документа ГК" для журнала установлено "При балансе".

Врядли такое только у нас.
Как бороться?

3.0. SP1 - 3-tier.

[DSV]

Агаааа!
Значит, не мы одни такие!

А серия на какие еще журналы подвешена?
Сколько человек одновременно на вводе сидят?

[dirigente]

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

[DSV]

А если 30 строк в журнал нашарашено с одинаковыми номерами?
Да, достаточно удалить.

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

[Тимур]

А не пробовали устанавливать генерирование номера документа ГК при создании журнала? А также не режим "Предупреждать дубликаты номеров", а "Запрещать"?

[dirigente]

Цитата:

Изначально опубликовано Тимур
А не пробовали устанавливать генерирование номера документа ГК при создании журнала?

Признаться, не понял - это где?

2. Насчет запрета дублирования номеров - пробовал. Вместо предупреждения генерится ошибка при предварительной разноске/разноске.

3. По-моему непрерывность НЕОБХОДИМА только для документов строгой отчетности, для которых требуется непрерывная нумерация (с-ф, например). Ну и плюс, конечно, экономия заданного числового множества (номерной серии). Так что Ваше решение, DSV, вполне нормальное, на мой взгляд. Попробую тоже отключить непрерывность. Если я не ошибаюсь, то действительно глючит именно выделение освобожденных номеров, что делается с целью обеспечения непрерывности.

[Тимур]

Свойство "Изменение номера документа ГК" для журнала.

А аудит потом как проводить?
Если номера документов ГК повторяются?

[dirigente]

Свойство "Изменение номера документа ГК" может принимать значения:
"При балансе", "Вручную", "Только один документ ГК".
Вы, Тимур, вероятно имеете ввиду последнее?
В случае с клиентскими платежами, на мой взгляд, логично все-таки "При балансе". Таким образом, одним документом ГК у меня связана операция поступления денежных средств от одного клиента на один банковский счет, например. И потом, проблема-то не в этом, а в выделении уже использованных номеров. Все же думается это ошибка и довольно грубая.

По поводу аудита - хороший вопрос. Честно говоря, не задумывался. Однако система позволяет дублировать документы ГК в принципе без каких-либо ограничений. Видимо, таким образом, пользователям (клиентам) отдается на откуп вопрос аудирования в том числе ...
Если Вам не трудно, приведите маленький пример граблей - если есть, конечно.

Целью документа ГК является логическое объединение проводок, вообще говоря, по хозоперациям. И в этом смысле Вы, Тимур, абсолютно правы. Т.е. принцип один журнал - один документ ГК хорош в случае с журналом ГК, и то только в случае когда в журнале отражается одна (или четко связанные) хозоперации. Т.о. предложение установить для журнала клиентских платежей "только один документ ГК" в таком случае вызывает недоумение.
В системе логика объединения может варьироваться - тоже, наверное, неспроста.
Конечно хочется более четкого понимания чем конкретно грозит повторение номеров документов ГК в общем случае.
Буду признателен, если кто-нибудь поделится живым опытом.

[ToRo]

Ax 3.0 SP1 трехзвенка
Была такая же проблема с нумерацией строк журналов. Никакие настройки в параметрах ГК и номерной серии никак не помогли.
В одном журнале (в частности в журнале платежей поставщикам) могли быть строки с номерами из других журналов.
Короче, очень похоже на ваш случай - лучше исправить иначе могут быть, например разные платежи по разным контрагентам с разными датами, но с одним номером ГК.
Исправляли наши разработчики.

[dirigente]

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

Придется действительно засучить рукава.

Кстати, если не секрет, можете привести примерно объем исправлений?

[ToRo]

Не секрет :-)
Но я не могу сказать, что и где менялось, т.к. сам не менял, а разработчик сейчас недоступен. Исправляли все за 3-4 часа. От меня попросили снять непрерывность нумерации строчек журналов.

[dirigente]

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

Надо будет обязательно докопаться до истины.

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


ОК. Спасибо большое!

[BOAL]

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

Этой же проблемой страдает складской журнал по подотчетнику (подотчетники разные, а документ ГК один на всех).... но там "Всегда новый" не поможет - там нужен свой мод.....

[dirigente]

Описываемую Вами, BOAL, проблему мы временно решили организационно. Т.е. таких ситуаций избегаем просто полностью заполняя строки (напр., в журнале кл. платежей) перед переходом к следующей строке. Благо коллеги сознательные - нареканий пока нет, но согласен - вариант интересный. Спасибо.
Однако я не понимаю как предлагаемое Вами решение позволяет избежать выделение ИСПОЛЬЗОВАННЫХ РАНЕЕ в других журналах (в частности, кл. платежей), номеров документов ГК? Или у Вас такой проблемы не было?

Видимо, в алгоритме есть какая-то особенность. По идее непрерывная нумерация предполагает, что в нумерации могут быть пропуски (два пользователя одновременно "резервируют" номера, но первый не использует своё множество) и номера могут по тем или иным причинам освобождаться.
Т.е. для полностью корректной работы необходимо проанализировать таблицу NumberSequenceList + все таблицы, в которых существуют записи с нумерацией из серии клиентских платежей. В результате выбираются неиспользованные/освобожденные номера и резервируются заново, при этом счетчик серии не увеличивается, естественно. Так вот серия для номеров документов ГК клиентских платежей у нас больше нигде не используется. Т.е. система не в состоянии корректно выделить свободные номера из ОДНОЙ таблицы, так получается? Совершенно ясно, что надо садиться и дебажить код. Просто я думал, что эту проблему уже многие решили ....

[DSV]

Стоп.
Да плюньте на демо-компанию, и разведите на каждый журнал по своей последовательности номеров. Это раз.

Два. Двойные номера ГК теоретически если рассматриваются совместно с датой проводки, то могут повторяться каждый день по разу. Но реально работает правило из доки по администрированию - номерная серия должна быть спроектирована так, чтобы как минимум 2 (два) года не пересекаться ни с какой другой серией.
Это становится понятно, когда залезаешь внутрь сопоставлений и книги покупок/продаж.

Кстати. Накладные от поставщика без номера или с одинаковым номером за одну дату - это просто з@дниц@ на ровном месте. У нас дикие бухгалтера завели кучу фактур от поставщиков с номером "б/н" на одну дату - было очень весело смотреть на строки книги покупок.


По поводу бесплатных докторов.
"Продаю геморрой за деньги" (с)
У нас имело место быть слипание документов оплаты. Пользуюсь (ПОД БОЛЬШИМ ВОПРОСОМ) структурой данных, приведенной в прицепленном файле. В номере ГК заменяю пробел на букву.
Только маленькое ограничение.
ДАЖЕ ДУМАТЬ О ПОДОБНЫХ ВЕЩАХ НУЖНО НА ТЕСТОВОЙ БАЗЕ! ^^-
Короче, если кто не понял - ответственности не несу, но слухами делюсь.

[Тимур]

Честно говоря так и понял, чем не устраивает один номер документа ГК по одному журналу. Один журнал - одна хозяйственная операция, и без разницы каков смысл данной операции: простые проводки в ГК или платеж поставщику.

[DSV]

Если у тебя там (в журнале) до черта поставщиков, а связь VendTrans <-> LedgerTrans осуществляется по Voucher & TransDate, то рука устанет связывать оперативный учет с бухгалтерским...

[Тимур]

"А с какой радости
Вы плодите, такие гадости"?

Один журнал - одна хозяйственная операция

[dirigente]

Это, Тимур, как посмотреть. Журнал с т.з. системы - не более чем пакет. А принципы объединения хозопераций, т.е. включения строк в пакет, это уже дело сугубо личное. Так что я более корректно, IMHO, говорить "одна хозоперация - один документ ГК". А вот описанный баг как раз и не позволяет опираться на такую концепцию.

[Тимур]

не согласен.
В том то и дело, что в аксапте, журнал - это не пакет
как, например, в Baan