AX2012R3: задание P-0001: Проводки канала

[PTG]

Доброго времени суток!

Установлено:
HQ: AX2012R3, MSSQL2012
Store: POS 6.3.00, MSSQL2008

Обмены с магазинами в части проводок магазинов настроены 1 раз в час.
Далее в рамках этого часа создаются журналы операций и разносятся.

Периодически имеем следующую проблему: в таблице RetailTransactionTable приходит чек, но в связанной таблице оплат RetailTransactionPaymentTrans записей по этому чеку нет. Аналогично со связанной таблицей продаж товара RetailTransactionSalesTrans - чек приходит, а в таблице продаж товара записей к этому чеку нет.
Не пришедшие записи, приходят через 1 час, в соответ-ии с установленным интервалом обмена.
Но за этот час создаются журналы и разносятся и чек получает статус "Разнесено" и платежи и товар остаются не разнесенными.

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

Спасибо!

[mazzy]

какой интересный случай...
а приложение чистое или модифицированное.

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

не помню уже для ax2012...

1. диагностика
в таблице RetailTransactionPaymentTrans
попробуйте посмотреть на поля TransDate+TransTime
и сравнить их с CREATEDDATETIME, MODIFIEDDATETIME

совпадают? отличаются по существу? отличаются на часовой пояс?

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

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

[AvrDen]

Цитата:

Сообщение от mazzy

1. диагностика
в таблице RetailTransactionPaymentTrans
попробуйте посмотреть на поля TransDate+TransTime
и сравнить их с CREATEDDATETIME, MODIFIEDDATETIME

совпадают? отличаются по существу? отличаются на часовой пояс?

Так поля TransDate+TransTime показывают Дату\время продажи на POS(когда был напечатан чек), а CREATEDDATETIME это время создания записи в АХ. Они не должны совпадать.

Цитата:

Сообщение от mazzy

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

Сергей, не подскажешь где в периодической операции по Созданию строк журнала операций есть данная настройка(чтобы создавать строки по проводкам, которые пришли больше часа назад)?

[mazzy]

Цитата:

Сообщение от AvrDen

Так поля TransDate+TransTime показывают Дату\время продажи на POS(когда был напечатан чек), а CREATEDDATETIME это время создания записи в АХ. Они не должны совпадать.

да, верно. я не точно выразился. приношу свои извинения.

в базе данных магазина в таблице RetailTransactionPaymentTrans
попробуйте посмотреть на поля TransDate+TransTime
и сравнить их с CREATEDDATETIME, MODIFIEDDATETIME

хотя... может это я с акс7 путаю...

Цитата:

Сообщение от AvrDen

Сергей, не подскажешь где в периодической операции по Созданию строк журнала операций есть данная настройка(чтобы создавать строки по проводкам, которые пришли больше часа назад)?

И опять же, выражаться надо точнее. Опять приношу свои извинения.

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

с отдельными полями дата-время подходящий фильтр настроить не получится.

[AvrDen]

В БД магазина сравнивали TransDate+TransTime и они совпадают с CREATEDDATETIME. Но факт, остается фактом)) Например, если задание P-0001 выполняется в 12:00:00, а записи в RetailTransactionTable, RetailTransactionSalesTrans были созданы в 11:59:59, а RetailTransactionPaymentTrans в 12:00:01, то RetailTransactionTable, RetailTransactionSalesTrans придут с пакетом в 12:00, а RetailTransactionPaymentTrans в 13:00. Соответственно возникают ошибки при создании журнала.
Такое чувство, что при заборе данных из POS в пакете стоит фильтр, что забирать данные из таблиц, с датой создания меньше определенного времени.

[mazzy]

Цитата:

Сообщение от AvrDen

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

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

[PTG]

Через профайлер видно, что забирает по счетчику из поля репликации, последнее забранное значение которого хранится в таблице логирования репликаций базы POS.

Через профайлер также увидели, что очередность выгрузки данных из таблиц определяется порядком следования подзаданий в задании P-0001 Проводки. И подзадание RetailTransactionTable выполнялось позже RetailTransactionPaymentTrans и RetailTransactionSalesTrans. Изменили название подзадания на 1RetailTransactionTable и оно теперь выполняется первым.
Надеемся на положительный результат.

[Alex_KD]

Цитата:

KB 3164451Payment transaction not getting pulled with transaction

PROBLEM
When you run the P-Jobs, the data of payment transaction is not getting created in the same RPF file of sales transaction. Another RPF is generated for the payment transaction with the same transaction ID of sales.

DESCRIPTION OF CHANGE
The changes in the hotfix make sure the data of payment transaction will get created in the same RPF file of sales transaction when you run the P-Jobs.

Fix из CU12. Какой у вас CU установлен?
Кажется в CU10 был еще один фикс для SyncLibrary...давно было, могу врать.

P-0001 обычно выполняется очень шустро. Как вариант можно выполнять чаще (если все остальное не помогает).

Вопрос, а зачем каждый час разносить? Мы делаем раз в день.

[AvrDen]

Цитата:

Сообщение от Alex_KD

Fix из CU12. Какой у вас CU установлен?
Кажется в CU10 был еще один фикс для SyncLibrary...давно было, могу врать.

Стоит CU10...

Цитата:

Сообщение от Alex_KD

P-0001 обычно выполняется очень шустро. Как вариант можно выполнять чаще (если все остальное не помогает).

Вопрос, а зачем каждый час разносить? Мы делаем раз в день.

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