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
Thanks
Roberto
USE [RPF_Nav_IS]
GO
/****** Object: Trigger [dbo].[PositivePay_DailyVoids] Script Date: 12/03/2010 14:54:49 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
– =============================================
– 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]
AFTER UPDATE
AS
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 is a very bad idea to add triggers to Navision original tables…
is this your
a custom Navision table OR a table for some other application?
If it IS a Navision table (or some AddOn’s table), you ARE NOT ALLOWED to tamper with it with SQL scripts in ANY way !!! This leads directly to data inconsistency and corrupt database !!!
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.