Текущее время: Чт, мар 28 2024, 22:33

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Чт, апр 25 2013, 14:55 
Младший специалист
Младший специалист

Зарегистрирован:
Пн, ноя 13 2006, 16:24
Сообщения: 59
Добрый день!

При формировании платежных поручений в F110 на основании документов ТАП, пользователи всегда указывают на вкладке "Параметры" весь перечень кредиторов. Т.е. в разделе "Счета", поле "Кредитор" проставляют диапазон: С 1 По ZZZZZZZ (Даже если делают одно ПП на основании единичного ТАПа - ограничивая затем выборку по номеру ТАП на вкладке "произвольный выбор" F110).

Такое указание полного диапазона кредиторов приводит к возникновению блокировок в процессе попытки одновременного формирования предложений разными пользователями (территориально по всей стране) - с ошибочным завершением формирования предложения и записью в журнале: "Пересечение с прогоном программы платежей ХХХ. Выполнение программы платежей прервано".

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

Спасибо!


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Пт, апр 26 2013, 10:54 
Старший специалист
Старший специалист

Зарегистрирован:
Ср, авг 30 2006, 20:05
Сообщения: 327
Как вариант - воспользоваться разделением Payment Porposal по Accounting clerk (русского логона нет, по-русски не знаю).
Тогда делать один (!) прогон по всем кредиторам, но в Payment Porposal каждый клерк будет видеть только своих кредиторов. Клерк указывается где-то в мастер записи кредитора на уровне БЕ.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Вт, окт 07 2014, 09:44 
Младший специалист
Младший специалист

Зарегистрирован:
Пн, ноя 13 2006, 16:24
Сообщения: 59
Добрый день еще раз!
Дело как раз в том, что в F110 блокируются счета кредиторов, которых пытаются одновременно использовать пользователи разных подразделений Заказчика (территориально отдаленных) при формировании предложений F110. Такими контрагентами могут быть крупные поставщики или банки. И когда по такому контрагенту в одном прогоне F110 уже создано предложение, а в другом пытаются сформировать предложение по этому же контрагенту, или при попытке одновременного формирования разных предложений F110 по одному контрагенту, система дает ошибки:
1. Ошибка при попытке формирования предложения по Кредитору, находящемуся в уже созданном предложении F110
2. Ошибка при одновременном формировании предложений по одному кредитору

F110 не формирует проводок на нашем проекте, отрабатывает только на основе ТАП.
Вот официальный ответ SAP Active Global Support по проблеме. В целом SAP говорит, что блокировки на уровне контрагентов нужны, чтобы не было задвоения платежей. Как-то отключить эту блокировку штатно нельзя:

Цитата:
Kindly note that blocking of vendor/customer accounts takes place at account level but not at document level.
The requested by you functionality of blocking based on involved documents rather than on business partners are not designed and is not planned to be realized by SAP Global Development Department in the standard.

The explanation of this system behavior is that when you schedule the proposal, it will never be allowed to launch another one at the same time because each proposal need to access the entire table (in order to avoid double payment). The system needs to access the whole table, and therefore, the vendor is blocked in the company code to avoid system inconsistencies. You block the vendor to be sure not to pay the same document/invoice twice. This will also happen if for example you create two documents and selects them in additional selections one at a time. The vendor will still be blocked. System will always check the Vendor number, regardless of the company code or the subdivision in order to assure that there is no duplication in payments.
This is the standard system design that is not planned to be altered. You should release the payment run or delete the proposal otherwise error FZ349 should arise.
SAP Standard System is designed in this way: when you run the F110 for a vendor/customer account, an entry in table REGUS is created to block the account.
Once this entry is create, there is no way to include this vendor in another payment proposal as you get the following error message. This is always done by the automatic payment program. The followings are some highlights with regards to system logic for the payment proposal block:
1. Payment proposal will be blocked by another vendor including the same vendor; but manual payment is blocked on item level, not on account level.
2. The block on item level is only relevant for manual clearing. A vendor that is in a payment proposal is blocked for all other payment proposals.
If no payment documents were generated, so you can delete the outputs via the menu option: 'Edit > Payments > Delete output'. Afterwards,
you can plan this payment run again or you can delete the proposal so that the vendor mentioned can be selected in another payment run (deleting the proposal seems to be your case). In order to solve the problem,please take the following steps: Transaction F110 -> Run date XX.XX.XX, identification YYYY -> Menu: Edit -> Payments -> Delete Output: This will delete all REGUH, REGUP and REGUS entries concerning this payment run.

Подскажите пожалуйста, как решалась подобная проблема на ваших проектах, если она имела место быть?
Спасибо!


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Вт, окт 07 2014, 10:43 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Пт, июл 08 2005, 13:07
Сообщения: 5273
Откуда: Cyprus
Пол: Мужской
Если я правильно помню, блокировка проходит на уровне БЕ. Если разные подразделения являются разными БЕ, то и блокировка не отработает.
А если это одна БЕ, то почему платят по отдельности?


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Вт, окт 07 2014, 10:50 
Младший специалист
Младший специалист

Зарегистрирован:
Пн, ноя 13 2006, 16:24
Сообщения: 59
БЕ - отдельные дочерние общества. Бизнес-сферы - отдельные филиалы внутри ДО (территориально удалены). Проблема внутри БЕ как раз между БС.
Перечисляют, например, выручку с филиалов в голову.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Вт, окт 07 2014, 11:42 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Пт, июл 08 2005, 13:07
Сообщения: 5273
Откуда: Cyprus
Пол: Мужской
darkduck написал:
А если это одна БЕ, то почему платят по отдельности?


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Вт, окт 07 2014, 12:04 
Младший специалист
Младший специалист

Зарегистрирован:
Пн, ноя 13 2006, 16:24
Сообщения: 59
Тогда я не понял вопроса. Видимо, потому что так построен процесс по бизнесу, компания слишком большая и территориально распределена, чтобы формировать все ПП в одном месте. В двух разных городах, которые представляют две разных Б-С (филиалы) в пределах одной большой компании (БЕ), два пользователя формируют платежные поручения из своих филиалов на одного контрагента. Например, перечисляют выручку за день в головную организацию или формируют платежки по перечислению ЗП. При этом они используют одного контрагента, что дает блокировку.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Вт, окт 07 2014, 12:45 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Пт, июл 08 2005, 13:07
Сообщения: 5273
Откуда: Cyprus
Пол: Мужской
Не вижу причин, почему одному и тому же контрагенту должны осуществляться два разных платежа от одной и той же (формально) компании.
Если бизнес-процесс не ложится в SAP, меняйте процесс.

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


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Пт, окт 10 2014, 08:26 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Вс, окт 17 2004, 11:34
Сообщения: 1551
Пол: Мужской
Nick-From написал(а):
Например, перечисляют выручку за день в головную организацию или формируют платежки по перечислению ЗП. При этом они используют одного контрагента, что дает блокировку.

Хм. Не катят примеры. Если это одно юрлицо, то это не платеж контрагенту, а перечисление между своими счетами. Пример: Еще в до-РЖДшную эпоху у МПС были соглашения о специальных счетах с обслуживающими банками. С подсобных доходных счетов ежедневно выручка перечислялась банком на основной доходный счет. Подсобные и основные счета могли быть как в одном, так и в разных банках. В результате вообще и никаких платежек оформлять не надо, и по банковской выписке такие операции вообще без участия юзера обрабатываются. Весь огромный (вторая на тот момент в стране по размеру оборота контора после Газпрома) денежный поток по основной деятельности обрабатывался полностью автоматически.
Про зарплату: два филиала одному сотруднику одновременно платежки на зарплату оформляют? Похоже на ересь какую-то.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Пт, окт 24 2014, 05:16 
Почетный гуру
Почетный гуру

Зарегистрирован:
Пт, янв 11 2008, 07:22
Сообщения: 1545
Откуда: Москва
Пол: Мужской
darkduck написал:
Не вижу причин, почему одному и тому же контрагенту должны осуществляться два разных платежа от одной и той же (формально) компании.
Если бизнес-процесс не ложится в SAP, меняйте процесс.

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

Пример про 27 филиалов в одном городе может и решается централизацией платежей из одного места, у меня же на предыдущем проекте запускалось 5-ть дочерних компаний крупной корпорации, каждая дочерняя компания имела от 20-ти до 40-а филиалов в нескольких областях России. При выработки концепции выплаты только из центральных аппаратов дочерних компаний или и из всех филиалов вопрос конечно встал, - вот какие аргументы против централизации были выдвинуты начальниками фин. служб, заметьте именно центральных аппаратов дочерних компаний, а не подразделений у которых, как Вы пишите, отобрали кормушку:
1. Очень большой объем мелких платежей, касающихся закупки материалов для вспомогательного производства, которые закупают на местах, а так же командировочные, подотчет, местные налоги, расчеты с сотрудниками (алименты, социальных выплаты и т.п.). Данные платежи обрабатывались и ранее в филиалах и при переходе на САП и с точки зрения руководителей финслужб и с моей точки зрения, как отвечающего за внедрение казначейства, было, что более оперативно управление формированием данного вида платежей на местах.
2. Существующая финансовая политика корпорации предполагает выплату части платежей не точечно доводя их из центрального аппарата до конкретных контрагентов, а именно доводя до расчетных счетов дочерних компаний - соответственно уже решение вопроса выплаты из центрального аппарата дочерних компаний или из их подразделений делегирован на решение руководства дочерних компаний. При существовавшей, до внедрения шаблона разработанного для всех дочерних компаний отрасли, системе расчетов в центральном аппарате за формирование платежных поручений (п/п) и отправку через банк клиент отвечал от одного до 3-х человек, которые формировали п/п по централизованным платежам центрального аппарата корпорации до точечных клиентов, по местным платежам центрального аппарата дочерней компании и переводу ДС в филиалы, если бы им пришлось еще и формировать п/п по местным платежам филиалов, то пришлось бы увеличивать количество формирующих п/п и обрабатывающих БВ на 15-25 человек, не уменьшая при этом штат на местах, т.к. на местах этим занимались люди которые вели еще и кассу. Убрать же кассу полностью не получалось (почему это отдельный вопрос, который можем отдельно обсудить). Получается что штат раздули бы, удобство оперативности формирования п/п убрали бы, - для чего не понятно?
Это по поводу:
Цитата:
Если бизнес-процесс не ложится в SAP, меняйте процесс.


Последний раз редактировалось ImpCons Пт, окт 24 2014, 06:34, всего редактировалось 2 раз(а).

Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Пт, окт 24 2014, 06:06 
Почетный гуру
Почетный гуру

Зарегистрирован:
Пт, янв 11 2008, 07:22
Сообщения: 1545
Откуда: Москва
Пол: Мужской
Цитата:
Не вижу причин, почему одному и тому же контрагенту должны осуществляться два разных платежа от одной и той же (формально) компании.
Примеров масса - закупаются для местных нужд материалы, продукты, хозтовары и т.п. у поставщика который имеет разветленную розничную сеть в регионе. Организация местных закупок не предполагает централизацию закупок в дочерней компании, а отдает их в филиалы.
Кроме того, примеры которые обсужу ниже:
Цитата:
Про зарплату: два филиала одному сотруднику одновременно платежки на зарплату оформляют? Похоже на ересь какую-то.
Sedlo, не ересь - если выплачивается ЗП по ведомости, то ЗП перечисляется техническому контрагенту "ЗП сотрудников" в банк же прикладывается сама ведомость - по которой банк конкретным сотрудникам деньги перечисляет. Для того чтобы в данной ситуации не было блокировки, на предыдущем проекте, который описал постом выше, создали технических контрагентов ЗП и технических контрагентов подотчетники для каждого филиала, а не по одному на всю дочернюю компанию и проблема с блокировками для данного вида платежей пропала.
Цитата:
Хм. Не катят примеры. Если это одно юрлицо, то это не платеж контрагенту, а перечисление между своими счетами. Пример: Еще в до-РЖДшную эпоху у МПС были соглашения о специальных счетах с обслуживающими банками. С подсобных доходных счетов ежедневно выручка перечислялась банком на основной доходный счет. Подсобные и основные счета могли быть как в одном, так и в разных банках. В результате вообще и никаких платежек оформлять не надо, и по банковской выписке такие операции вообще без участия юзера обрабатываются. Весь огромный (вторая на тот момент в стране по размеру оборота контора после Газпрома) денежный поток по основной деятельности обрабатывался полностью автоматически.
И этот пример прокатит. Потому что в первой по обороту в стране компании, по твоим же словам )), т.е. Газпроме, разрешают собственную выручку использовать на определенные статьи расхода, а безакцептное списание выручки со счетов филиалов это не позволит сделать.
Но и этот вопрос у нас был решен заведением технических контрагентов на каждый филиал, а не одного на дочернюю компанию в целом.

Резюмирую в общем - для того чтобы избежать блокировок при прогоне АПП, я проговорил с фин.службой в одной дочерней компании, инициировал разговор в остальных 4-ех, выяснили по каким платежам возможны прогоны АПП одновременно в нескольких филиалах, выяснилось что именно больше по ЗП и подотчетникам при выплатах по ведомости, по остальным видам платежей может и будут единичные ситуации, но они по мнению фин.служб не являются критичными. Развели технических контрагентов по филиалам и основные проблемы с блокировками устранили еще до их появления.
Не скажу что заведение даже технических контрагентов прошло быстро, - пришлось собирать мнение финслужб 5-ти дочерних компаний и мнение сотрудников принимающей эксплуатирующей организации по САП-у у которой эти проблемы уже были на запущенном в продуктив проекте в той же корпорации в другой дочерней компании, для того чтобы убедить ответственного за FI и ответственного за всю функциональную часть на нашем проекте. И преодолевал доводы ответственного за всю функциональность типа - давайте запустимся в опытную эксплуатацию без разделения контрагентов и если получим замечания, то устраним, заручался для этого поддержкой РП проекта внедрения на одной из 5-ти дочерней компании.
В общем с техническими контрагентами проблема решается, с реально существующими нет, но в моем случае она была не существенной.
Кстати ответственная за FI на нашем проекте предлагала подлом F110 на снятие блокировки при прогоне, мало того, на предыдущем проекте она смогла обосновать не разделение технических контрагентов по филиалам, тем что можно подломать, в итоге на том (предыдущем) проекте, она подломала снятие блокировки при выравнивании задолженности и оплат, т.к. она за выравнивание отвечала, а за казначейство на том проекте отвечала, та, которая была ответственной за всю функциональность уже на нашем проекте и снятие блокировки при АПП на том проекте, где она отвечала за казначейство, досталось благополучно принимающей эксплуатирующей организации по САП-у и они в песочнице даже реализовав подлом, решили спросить САП СНГ мнение о таких действиях и получив его в продуктив все таки его не понесли и для нашего проекта стали своеобразным референсом в данном вопросе.

PS: Все персоналии, в описанной мной ситуации, вымышлены и совпадения случайны :D, прошу никого не принимать на свой счет.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Пт, окт 24 2014, 08:08 
Почетный гуру
Почетный гуру

Зарегистрирован:
Пт, янв 11 2008, 07:22
Сообщения: 1545
Откуда: Москва
Пол: Мужской
Nick-From написал(а):
Добрый день!

При формировании платежных поручений в F110 на основании документов ТАП, пользователи всегда указывают на вкладке "Параметры" весь перечень кредиторов. Т.е. в разделе "Счета", поле "Кредитор" проставляют диапазон: С 1 По ZZZZZZZ (Даже если делают одно ПП на основании единичного ТАПа - ограничивая затем выборку по номеру ТАП на вкладке "произвольный выбор" F110).

Такое указание полного диапазона кредиторов приводит к возникновению блокировок в процессе попытки одновременного формирования предложений разными пользователями (территориально по всей стране) - с ошибочным завершением формирования предложения и записью в журнале: "Пересечение с прогоном программы платежей ХХХ. Выполнение программы платежей прервано".

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

Спасибо!

Блокировка проходит не по всем контрагентам указанным в диапазоне, а именно по тем кого в дополнительным выборе еще ограничили. Если кто то в произвольном выборе ничего дополнительно не указал, то тогда да, всех контрагентов и заблокирует.
По поводу методов борьбы с блокировками:
1. Централизация выплат крупным поставщикам - но так закупки в компании должны быть организованы
2. Разделение технических контрагентов - ЗП, подотчетники, может даже выплата местных налогов, по филиально.
3. В крайнем случае попытался бы проанализировать возможность схемы создания на контрагентов, выплаты по которым не удается централизовать, технических контрагентов на каждый филиал, т.е. контрагент такой то в филиале таком то, платеж тогда делать на технического, указывая альтернативным основного, заведенного одного на компанию.
На проекте который описал выше - первый пункт был организационно принят еще до нас, второй пункт реализовали сами, 3-ий пункт не понадобился.
Вполне возможно что его и нельзя реализовать из-за сложности начисления задолженности именно на технического и отражения во всей отчетности в том числе и по НДС реального, но если бы перед мной стояла задача решения проблемы блокировок я обязательно проанализировал бы этот вариант.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Чт, янв 31 2019, 12:44 
Начинающий
Начинающий

Зарегистрирован:
Вт, апр 18 2006, 15:23
Сообщения: 5
ImpCons написал:
Цитата:
Кстати ответственная за FI на нашем проекте предлагала подлом F110 на снятие блокировки при прогоне, мало того, на предыдущем проекте она смогла обосновать не разделение технических контрагентов по филиалам, тем что можно подломать, в итоге на том (предыдущем) проекте, она подломала снятие блокировки при выравнивании задолженности и оплат, т.к. она за выравнивание отвечала, а за казначейство на том проекте отвечала, та, которая была ответственной за всю функциональность уже на нашем проекте и снятие блокировки при АПП на том проекте, где она отвечала за казначейство, досталось благополучно принимающей эксплуатирующей организации по САП-у и они в песочнице даже реализовав подлом, решили спросить САП СНГ мнение о таких действиях и получив его в продуктив все таки его не понесли и для нашего проекта стали своеобразным референсом в данном вопросе.

PS: Все персоналии, в описанной мной ситуации, вымышлены и совпадения случайны :D, прошу никого не принимать на свой счет.


Долго смеялась :) отключали проверку НЕ на блокировку при пересечении прогонов АПП, а на блокировку контрагента в прогоне АПП при проводке, потому что в решении это было неактуально. Так что, не путайте, уважаемый, понятия. Да и свечку Вы не держали, когда "она обосновывала не разделение технических контрагентов..." :))).
И, кстати, это решение по отключению проверки при проводке на блокировку в АПП было реализовано и "на предыдущем проекте" и на текущем. И даже растиражировано еще на больше десятка ДО. И работает в продуктивных системах, кажется, с 2013 года.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Чт, янв 31 2019, 16:52 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, дек 20 2007, 18:21
Сообщения: 1613
Подкину тоже вам тут мега решение которое было реализовано консультантом на проекте. Вышибать пользователя из системы из транзакции выравнивания во время прогона АПП. Решение в последующем было выпилено мной конечно :mrgreen:

_________________
я твой сап эфай внедрял
BAdI-позитив
Взять немножечко абопу, сунь туда кошачью *опу, RFC лапки, БТ старой бабки, на медленном базиснике переносить, тестовое окружение материть, снимать SAT пенку, биться головой о стенку, охапка тайм-шитов, отчет готов!


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Пересечения с чужими прогонами программы платежей F110 у разных пользователей
СообщениеДобавлено: Чт, янв 31 2019, 17:43 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Ср, фев 21 2007, 08:50
Сообщения: 1570
Откуда: Пермь
Пол: Мужской
Kengur написал(а):
Подкину тоже вам тут мега решение которое было реализовано консультантом на проекте. Вышибать пользователя из системы из транзакции выравнивания во время прогона АПП. Решение в последующем было выпилено мной конечно


Это мегарешение какой проблемы?)) Тут обсуждается невозможность прогона по блокированному в БЕ контрагенту в таблице REGUS. То есть два живых сформированных предложения по одному и тому же контрагенту.

Кстати, полезная инфа для всех. Ошибочно полагать, что система блокирует контрагента, если он указан в параметрах прогона в ограничениях. Этого недостаточно для блокировки. Контрагент блокируется только в том случае, если по нему в предложении (и только в нем) есть хотя бы одна зеленая позиция. То есть если позиция красная (например, выставлен код блокировки) и других позиций по контрагенту в предложении нет, то с этим контрагентом можно делать новое. Если позиция была красная, но "позеленела" в результате ручной обработки предложения, то это в свою очередь контрагента блокирует для других прогонов. Блокировка из REGUS снимается, когда будет совершен продуктивный прогон или когда зеленая позиция будет исключена из предложения (то есть снова покраснеет).

Далее. При чем тут собственно транзакция выравнивания? При запущенной транзакции выравнивания по кредитору выставляется стандартная блокировка по кредитору (через ENQUEUE), F110 с таким кредитором не пройдет. Теперь рассмотрим с другой стороны. При наличии зеленых позиций (см. выше) в предложении, такие позиции АВТОМАТИЧЕСКИ система исключит из транзакций выравнивания и не покажет их в выборе позиций, даже если в выравнивание войдет кто-то с незавершенным прогоном. Пользователь такие позиции в выравнивании попросту не увидит и выполнить выравнивание не сможет. Аналогично она поступает и с позициями продуктивного прогона F110 без проводок (ждет платежку и выравнивания через выписку).

Таким образом, проблемы конфликта транзакций выравнивания и транзакции F110 вообще не существует, кто бы первым и в какую транзакцию ни зашел. Всех дельцов, кто что-то дописывает искусственно или тем более кого-то вышибает - отлавливать и связывать.
Проблема параллельных прогонов в F110 - да, существует. Но только в том случае, если по кредитору в БЕ есть хотя бы одна зеленая позиция в одном из предложений.

_________________
Алё, это Пакистан? Нам нужен один килограмм


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB