Sales Pack - XInvoice

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • hom
    replied
    Hi Yuri,

    thanks again for the great work. You asked about suggestions. Here we go.

    I suggest a new section "Payment information" under Invoice. It should contain the following payment methods:
    Code (BT-81) English text (BT-82) German text (BT-82) Information is to be transferred for
    30 Credit transfer Überweisung BG-17
    58 SEPA credit transfer SEPA Überweisung BG-17
    59 SEPA direct debit SEPA Lastschrift BG-19
    48 Bank card Bankkarte BG-18
    54 Credit card Kreditkarte BG-18
    55 Debit card Debitkarte BG-18

    BG-17: Informations for (BT-81) code 30 and 58
    Assignment Name (EN) Name (DE) Fieldtype Enforcing
    BT-85 Payment account name Kontoinhaber Free text field No
    BT-84 Payment account identifier Kontonummer/IBAN Free text field Yes
    BT-86 Payment service provider identifier BIC Free text field Yes (Code 30)
    No (Code 58)
    BT-83 Remittance information Verwendungszweck Free text field No
    BT-20 Payment terms Zahlungsbedingungen Free text field No

    BG-19: nformations for (BT-81)code 59
    Assignment Name (EN) Name (DE) Feldtyp Enforcing
    BT-89 Mandate reference identifier Mandatsreferenznummer Free text field Yes
    BT-90 Bank assigned creditor identifier Gläubiger ID Free text field Yes
    BT-91 Debited account identifier Kontonummer/IBAN Free text field Yes

    BG-18: nformations for (BT-81) code 48, 54 and 55
    Assignment Name (EN) Name (DE) Feldtyp Enforcing
    BT-87* Payment card primary account number Kartennummer Free text field No
    BT-88 Payment card holder name Name des Karteninhabers Free text field No
    *Note to BT-87
    In accordance with the security standards applicable to credit cards, an invoice may not contain the full card number. However, it must show the last 4 to 6 digits of the card. Suggestion "****1234" (show the last four digits).


    Suggestion:
    Add under Administration > Sales Pack > Settings > Electronic Invoicing a new section with account information. It should contain the fields:
    BT-85 Payment account name Kontoinhaber Free text field
    BT-84 Payment account identifier Kontonummer/IBAN Free text field
    BT-86 Payment service provider identifier BIC Free text field
    These should then also be used as preallocation for the BT-81 code 30 and 58.


    Other task:
    Please also include the "Description" field from the invoice module in the E-Invoice as an "Invoic note" (BT-22). The field already exists, it is just not yet included in the E-Invoice schema.

    Thanks for the great development. Feel free to ask, if anything is unclear.

    Leave a comment:


  • yuri
    commented on 's reply
    The question is not about payments but payment means. E.g. credit card, cash, etc.

  • dodom2
    replied
    We often accept multiple payments per invoice. Its pretty common in the states.

    Leave a comment:


  • yuri
    replied
    If anybody have thoughts and ideas regarding payment means, how we could better implement it, please share.

    As I understand, in Germany an invoice can have only one payment mean. Would we need multiple ones? As the standard allows multiple payment means per invoice. Maybe in some countries it's a common practice to have multiple payment means?

    Leave a comment:


  • yuri
    commented on 's reply
    I don't have an example.

    Bind implementation https://docs.espocrm.com/development/di/#binding

    Interface:
    Code:
    Espo\Modules\Sales\Tools\Invoice\EInvoice\Preparator
    To be bound to a custom implementation.

    The default implementation:

    Code:
    Espo\Modules\Sales\Tools\Invoice\EInvoice\DefaultPreparator
    To be called inside the custom implementation.

    This should be trivial for programmers who have experience in OOP.

    This is not an official guideline. No guarantee that the implementation will not change in the future.
    Last edited by yuri; 09-13-2024, 10:11 AM.

  • Bernhard
    replied
    Hi Yuri,

    I was busy for a while and just saw yesterday how much you have implemented. Great job!

    Leave a comment:


  • hom
    replied
    Hello Yuri,

    do you have an example or instructions on how and where the preparator interface can be addressed?​

    Leave a comment:


  • hom
    replied
    Thank you very much, that sounds excellent!

    Leave a comment:


  • yuri
    replied
    Added a preparator interface. Developers can add additional items to an E-Invoice from custom fields and related entities.

    Leave a comment:


  • yuri
    replied
    Thanks for input.

    I've added the standard ProfileID value for XRechnung in the new version.

    The online validator for 3.0.1 does not catch when the ProfileID is missing for some reason.

    Regarding Payment Instruction. There's no the Payments functionality in Sales Pack at the moment. It was planned for the future. Before we have it implemented, I'm not sure how we could make it possible for users to specify values for an E-Invoice.

    Leave a comment:


  • hom
    replied
    Hello Yuri,

    Firstly, I would like to thank you for the great job you did implementing e-invoice!
    It must have been a lot of work, especially as there are so many different standards.

    I installed the latest sales pack 2.4.1 and made all possible adjustments so that I could create an e-invoice according to the XRechnung standard. The implemented validator does not show any errors either, but there are fields that are additionally required and I don't know whether I simply haven't found them or whether they are not (yet) implemented.

    The following is missing for me:

    1) With the XRechnung Standard 3.0.1/3.0.2 the following field is required: ProfileID. The field references the BT-23 requirement, where a static value is stored according to which rules or standards the invoice was created. For Germany (as an example), the value "urn:fdceppol.eu:2017oacc:billing:01:1.0" would be entered. As this may differ in other countries, it would certainly be helpful to store the ProfileID as an additional field in the ‘Seller Information’. If there is no general list, at least a free field would be useful.

    2) It is also necessary to store the payment information. This is to be used as section ‘PAYMENT INSTRUCTIONS’ BG-16 and contains information on how the payment should be made. I am not quite sure where this information is to be stored in the ESPO or whether this setting has not already existed for a long time and I have just not found it.
    The PAYMENT INSTRUCTIONS have the following attributes
    - Payment means type code : Code [1]
    - Payment means text : Text [0..1]
    - Remittance information : Text [0..1]
    - CREDIT TRANSFER : CREDIT TRANSFER [0..*]
    - PAYMENT CARD INFORMATION : PAYMENT CARD INFORMATION [0..1]
    - DIRECT DEBIT : DIRECT DEBIT [0..1]

    Please let me know if I can make the settings myself or if they already exist.
    I am happy to continue supporting the process and thank you again for the great work!

    Leave a comment:


  • yuri
    replied
    Yet another problem to solve is generating CII. Currently we only have UBL implementation.

    Leave a comment:


  • item
    commented on 's reply
    i have "like" on github.. maybe the PR will be merged

  • user_4711
    commented on 's reply
    thank you! i'll keep an eye on it, too.

  • ThomasB
    replied
    Originally posted by user_4711i

    sounds great, but i only found this discussion about PDF/X PDF/A Support in dompdf https://github.com/dompdf/dompdf/discussions/3191

    @user_4711​ Look here: https://github.com/dompdf/dompdf/pull/3269
    Last edited by ThomasB; 06-12-2024, 03:11 PM.

    Leave a comment:

Working...