Auto Warning Notice with Last name?

[spliner]

Hi,

I am new to filemaker and database. I want to make a database which give me auto notification pop up which display names of people who did not pay on certain date.

For example, person A need to pay for product after 30 days.

I want to know this person's name so I can contact that person.

Is it possible to do that?

[John Mark Osborne]

I have an example file on my web site demonstrating how to do this:

http://www.filemakerpros.com/Overdue2.zip

[LaRetta]

I am with John 100% on theory but I prefer a different approach. This approach uses Status(CurrentDate) or Get(CurrentDate) and yes the calculation is unstored but it resides in a table with very few records and it is NOT searched anyway. It displays when needed (just like a pop-up) but pop-ups can ... emm ... pop up and they disrupt normal work-flow. But when a Customer is overdue it effects ALL admin and managers and you are right to want that information displayed, tracked, and acted upon when needed. It will matter to:

• Receptionist: When an Overdue Customer calls (who can then ensure a connection with Accounting, ie, 'Yikes! This customer is way-late! Deposit the check or credit their card before they change their mind or run out of money again!).
  
• Sales Rep: Who is preparing a proposal for that Customer (that maybe the Rep's time shouldn't be wasted on new proposal until Customer financials are again stable).
  
• Shipping: Who just received backordered product for this Customer (can then check with Management on whether to ship the product or use it to recoop some of the business' lost revenue if debt isn't paid).
  
• Accounting: Of course. It's what they do.
  
• Business Manager/Management: Attempting to coordinate Receivables' bottom-line vs. business purchases etc.
  
• Owner: Are the employees doing their job (not dropping the ball) and providing an up-to-date State-of-the-Agency view (along with other financial).
  

I use a portal. This 'hit list' of Customer names sits on most sub-menus (Sales, Shipping, Admin, Management). Every time employee returns to their (User table) home page (which they must), they see a) what they need to know and : work they need to complete. These Position-based sub-menus are almost identical to (and work in conjunction with) Privilege Sets. Where best to place an Overdue portal will vary per business (and per Position) but you get the drift. When Invoice status changes (check received, Accounting negotiates date extension, NSF assessed or checks/products returned), portal updates instantly and display is quick because the relationship is filtered (filter options abound and can be tied into the Rules table). It doesn't depend upon whether the bookeeper is on vacation (nobody needs to remember to do that part of her job) or whether admin is out sick (and someone needs to bill credit cards) and so forth throughout the business. If a ball is dropped (or information needs to be communicated) then it will happen naturally because it will be in their faces.

Customer table contains GracePeriod (auto-enter number) based upon whether 1) Chain store (extended additional 3 weeks), 2) pay method (credit card 0 grace, COD 14 working-day grace), 3) personal friend of Owner and so forth. Owner controls the 'rules' from Browse. Owner/Management adjusts the Customer GracePeriod (which is audit-tracked). The Invoice ODD (OverDueDate) is auto-enter on Invoice = InvoiceDate + Terms + Customers::GracePeriod and Accounting can adjust ODD (which is also audit-tracked). The Grace Period handicaps our Customers and, just as with horse racing, the purpose of handicapping is to 'bring all horses to the wire' simultaneously - NOT by days past due but by the rules established. This synch method ensures that, whether credit card customer wasn't billed the day of shipment OR a Chain breeches by 4 weeks - if they are in this portal then 'Houston? We have a problem.' Portal sorts by Strike (which is determined by Rules and modified by Management). Overdue Customers are NOT one person's problem ... they effect an entire business. So don't rely on one person remembering to fire a script to communicate it.

I apologize for the length. But administration is my passion and too often I see important information constrained to one person who, on the very day they have an important task, a family member gets sick and they need to drop the ball. Portals are self-sustaining and I felt the principle (why a portal) was more important than the method (how do I create a portal) so I presented the reasoning instead of a demo.

LaRetta :wink2: