Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invoice paid by a Third Party - party known #42

Open
svanteschubert opened this issue Oct 24, 2023 · 2 comments
Open

Invoice paid by a Third Party - party known #42

svanteschubert opened this issue Oct 24, 2023 · 2 comments

Comments

@svanteschubert
Copy link
Owner

svanteschubert commented Oct 24, 2023

Background

Invoice payable by a third party known at the time of invoicing

French Use Case n°3: Invoice to be paid by a third party designated at the time of invoicing

The invoice is sent by the supplier to the buyer, who is responsible for forwarding it to the third-party payer once it has been settled or validated.

For all invoices sent by the PPF or a PDP :

  • The third-party payer can be identified on the invoice in the "INVOICE PAYER" block (EXT-FR-FE-BG- 02).
  • On the PPF, the invoice and its life cycle are not transmitted to the third-party payer; they will be made available to him, if it has an account on Chorus Pro.
  • PDPs are responsible for managing access to the third-party payer lifecycle.
  • The life cycle can be updated by the third-party payer, via a PDP or directly on the PPF.

image

Figure 2: Invoice to be paid by a third party designated for invoicing

The specific features of the life cycle or associated processes are :

  • The life cycle can be updated by the third-party payer directly on the PPF or via one of the PDPs. An account on one of these platforms will be necessary
  • Transmission of flow 1 and e-reporting of payment data by supplier

The services offered by PPF are :

  • If both the buyer and the third party are connected to the PPF, the latter will be able to view the invoice and its lifecycle.
  • If both the supplier and the third party are connected to the PPF, the latter will be able to view the invoice and its life cycle.
  • Actors connected to the PPF will be notified by a lifecycle flow in the event of an invoice status change.

The steps in case 3 are :

Step

Stage name

Responsible player

Description

1Invoice creationSupplierThe supplier creates the invoice (flow 2) via PDP 1, which sends it to the buyer. At the same time, PDP 1 sends the invoice's regulatory data (flow 1) to the PPF.

2

Receiving stream 1

PPF

3Receipt of invoice

Buyer

The buyer's platform (the PPF in the example) provides him with the invoice for checking. The buyer processes the invoice as required and updates the status.
4Invoice processing and status update
5Receipt of invoice statusSupplierThe supplier receives the invoice status after the invoice has been processed by the buyer according to the lifecycle procedure.
5bInformation on the invoice processingSupplierThe supplier provides information on the correct processing of the invoice (depending on the platforms' commercial offer).
6Invoice paymentThird partiesThird party pays supplier
7Invoice collectionSupplier

1° The supplier collects the invoice and updates the invoice collection information with the status "collected".

2° The supplier's PDP 1 transmits payment data to the PPF

3° Depending on the platforms' commercial offer, it can send a life cycle of the collection to the third party and/or the buyer.

7bInvoice collection informationSupplier
8

Go to à update at status

"cashed

Supplier
9

Reception from status

"cashed

BuyerThe buyer's platform (PPF in the example) receives the incoming payment status transmitted by the supplier's PDP 1.

NOTE:
The text/pictures of this use case no. 3 were taken from the French government site!
The text was extracted from V2.3 - deepl English DOCX and any pictures were taken from V2.2 - original English PDF)

@edmundgray
Copy link
Collaborator

edmundgray commented Nov 6, 2023

Paid amount (BT-113) is set to the amount paid in advance and Bt-115 (Amount due for payment) is set to zero or the remaining balance if not fully paid.

related issues are #54, #49, #56, #53

@edmundgray
Copy link
Collaborator

edmundgray commented Nov 6, 2023

Paid amount (BT-113) is set to the amount paid in advance and Bt-115 (Amount due for payment) is set to zero or the remaining balance if not fully paid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants