I need catch check we avoid with setting the bank requet.
to do that I created a table with form the bank request and create trigger to chatch it.
When running production give error whe A/P Person do consolidation he can select check a error comming.
I don’t if I need to do other thing other way please give advise
/****** Object: Trigger [dbo].[PositivePay_DailyVoids] Script Date: 12/03/2010 14:54:49 ******/
SET ANSI_NULLS ON
SET QUOTED_IDENTIFIER ON
– Author: Roberto Londono
– Create date: 12/1/2010
– Description: Capture all check has been avoid and write table Paycheck
ALTER TRIGGER [dbo].[PositivePay_DailyVoids]
ON [dbo].[River Point Farms$Check Ledger Entry]
Insert into RPF_Finance_PositivePayBanking (AccountNumber,AccountType,CheckSerialNo,TransactionAmount,IssueDate,Payee,VoidIndicator,Stopindicator)
SELECT ‘0000034576892734’ AS [Account Number], ‘D’ AS [Account Type], [Check No_] AS [Check Serial #], Amount AS [Transaction Amount], [Check Date] AS [Issue Date], SUBSTRING (Description ,1,20) AS Payee,‘V’,‘S’
FROM inserted as I
WHERE (I.[Entry Status] = 4)
It’s true. We had a consultant delete the Sales Header in trigger that fired one time. So happened that that trigger fired during posting and when it came time to delete it in the posting Codeunit it no longer existed. We couldn’t post for days because we couldn’t find the code.
I would think about your solution more. There are probably better ways to accomplish the business need.
Besides all the issues already highlighted, more exist. After first backup-restore ALL non-Navision tables, indexes, triggers, views, stored procedures, etc etc will vanish without a trace. If SQL server backup is used, not the Navision one, then these remain, but these will be certainly lost during Navision upgrade. Not to speak about the fact, that after a couple of years there might be nobody available, who is aware of such modifications in DB structure, and when something goes wrong, finding the reason and repairing may be impossible.
If you need some Navision data to be copied to some other DB -never mind for what purpose- the correct approach is doing it from that other DB side. The only allowed direct activitiy in Navision SQL DB by some T-SQL scripts and bypassing Navision logics is SELECT FROM, and never INSERT / UPDATE / DELETE - or custom triggers as you plan to do.
You can hardly know HOW MANY tables actually are affected, in addition to obvious ones there are many supplemental, then there is C/AL code in tables themselves (aka triggers), which is NOT executed, when you do something directly by SQL script. And this leads to database inconsistency and BIG problems.