Alkimia/Usecases/payment: Difference between revisions

From KDE Community Wiki
mNo edit summary
 
(11 intermediate revisions by the same user not shown)
Line 19: Line 19:
#open the list of unchecked invoices.
#open the list of unchecked invoices.
#check the unique identifier any of the invoice and see which document type it is.
#check the unique identifier any of the invoice and see which document type it is.
#*The data which is used for detection should come as Key-Value pairs from the client, for example kraft would send this for a document:<br/>              Document-ID:4711<br/>Name:    Strawinsky<br/>First Name:  Elena<br/>Document Type: Invoice<br/>
#*The Alkimia Service in turn would associate the strings with the created transaction.When a payment comes in, it searches for the strings "4711", "Strawinsky", "Elena" and "Invoice". If it finds for example "Elena", it would ask the user something like: "The online banking record XY contains the word Elena which is associated as First Name with the transaction Z.<br/>This transaction expects a payment.<br/> Is that online record representing the payment for the transaction?"
#Ask user if the expected payment is filed with the unique identifier.
#Ask user if the expected payment is filed with the unique identifier.
#If the user validates it then mark the payment to be received.
#If the user validates it then mark the payment to be received.
#update the changes.
#update the changes.
====ALTERNATE FLOW====
====ALTERNATE FLOW====
#If the user says the unique identifier is invalid, then send the invoice to a “ invalid invoices" folder
#If the user says the unique identifier is invalid, then send the invoice to a “ invalid invoices" folder
Line 30: Line 33:


====USE CASE DIAGRAM====
====USE CASE DIAGRAM====
[[http://community.kde.org/File:UseCase_Payment_Detection.png usecase diagram]]
[[File:UseCase_Payment_Detection.png|550px|center]]
----
----


==DATA MODEL==
==DATA MODEL==
===ER Diagram===
===ER Diagram===
[[http://community.kde.org/File:ER_DIG_Payment_Detection.png ER Diagram]]
[[File:ER_DIG_Payment_Detection.png|550px|center]]
 
===Entities===
===Entities===
====USER====
====USER====
====Attributes====
;Related To
#'''No. Of Pending Invoices :''' No. of invoices the user hasnt marked yet or haven't declared yet if they are valid or invalid
Entity Invoice
====INVOICE====
====INVOICE====
====Attributes====
;Attributes
#'''mark: ''' If the invoice is marked or not.
#'''valid: ''' If the invoice received is valid or invalid or is not even payed<br/> So the valid can have 2 values: valid,invalid, or it can be NULL<br/>the no. of invoices with NULL 'valid' value can be counted to form no. of pending invoices.
If the invoice is marked it means the user has validated it(marked it as valid or invalid).
#'''Unique Identifier: ''' The unique identifier related to each invoice. It would be different for each and every invoice.It will also tell us about the type of invoice.
#'''valid: ''' If the invoice received is valid or invalid
;Related To
#'''User:''' Who issued the invoice.
#'''Payment:''' which payment the invoice is processing.A single invoice can have multiple payments.
 
====PAYMENT====
;Attributes
#'''Payer:''' Who is the Payer?
#'''Date:'''
#'''Time:'''
#'''Account:''' Account where you received the Amount.
#'''Memo:'''
;Related To
:A single Payment can be processed by multiple invoices by splitting it and applying it against multiple invoices.

Latest revision as of 20:36, 17 June 2011

PAYMENT DETECTION

INTRODUCTION

As soon KMyMoney or Skrooge becomes aware of an incoming payment, either through online banking or manual entry, it should

  1. try to detect an unique identifier
  2. validate if there is an expected payment filed with this unique identifier
  3. if so, let the user validate if the detection is correct (optional)
  4. mark the payment to be received

Example: Elena issues an invoice with Kraft over 364 Euro, due in 10 days. She marks the invoice to be sent in Kraft. In KMyMoney and Skrooge the amount of 364 Euro shows up as expected money together with the document id number, date and addressee of the invoice. Four days later, Elena checks the accounts via online banking. One transaction record contains the document id and the finance manager asks Elena if she can confirm that this is the money paying the invoice. She confirms that.\\Next time she starts Kraft she sees that the invoice is marked as payed.

ACTORS

  1. USER
  2. Finance Manager

PRECONDITIONS

  1. must have an installed financial manager.
  2. law requirements must met for document identifier of the incoming voice.
  3. The coming invoice must have a unique identifier attached to it.

BASIC FLOW

  1. open the list of unchecked invoices.
  2. check the unique identifier any of the invoice and see which document type it is.
    • The data which is used for detection should come as Key-Value pairs from the client, for example kraft would send this for a document:
      Document-ID:4711
      Name: Strawinsky
      First Name: Elena
      Document Type: Invoice
    • The Alkimia Service in turn would associate the strings with the created transaction.When a payment comes in, it searches for the strings "4711", "Strawinsky", "Elena" and "Invoice". If it finds for example "Elena", it would ask the user something like: "The online banking record XY contains the word Elena which is associated as First Name with the transaction Z.
      This transaction expects a payment.
      Is that online record representing the payment for the transaction?"
  3. Ask user if the expected payment is filed with the unique identifier.
  4. If the user validates it then mark the payment to be received.
  5. update the changes.

ALTERNATE FLOW

  1. If the user says the unique identifier is invalid, then send the invoice to a “ invalid invoices" folder



USE CASE DIAGRAM


DATA MODEL

ER Diagram

Entities

USER

Related To

Entity Invoice

INVOICE

Attributes
  1. valid: If the invoice received is valid or invalid or is not even payed
    So the valid can have 2 values: valid,invalid, or it can be NULL
    the no. of invoices with NULL 'valid' value can be counted to form no. of pending invoices.
  2. Unique Identifier: The unique identifier related to each invoice. It would be different for each and every invoice.It will also tell us about the type of invoice.
Related To
  1. User: Who issued the invoice.
  2. Payment: which payment the invoice is processing.A single invoice can have multiple payments.

PAYMENT

Attributes
  1. Payer: Who is the Payer?
  2. Date:
  3. Time:
  4. Account: Account where you received the Amount.
  5. Memo:
Related To
A single Payment can be processed by multiple invoices by splitting it and applying it against multiple invoices.