3.6.8 breaks Pain pain.008.001.02

[3frogx]

Hello,

The xml export for direct debit has been broken for a few days. I assume it has to do with the new version.

Not all open payments are taken into account and the xml file has a "new" structure. For example, the postal address is included.

greetings, volker

We use pain.008.001.02. Worpress 6.0, Woocommerce 5.6

[dennisnissle]

Hi there,

Not all open payments are taken into account

That sounds weird. What is missing? Is there any rule applicable to the orders missing? We migrated to using wc_get_orders instead of using a custom meta query. See: https://github.com/vendidero/woocommerce-germanized/blob/master/includes/gateways/direct-debit/class-wc-gzd-gateway-direct-debit.php#L406

For example, the postal address is included.

Yes, we've added the data (required by pain.008.003.02). Seems to be that the data is valid in pain.008.001.02 too as the library explicitly includes the data for this format too: https://github.com/php-sepa-xml/php-sepa-xml/blob/806c0530f9f9a8001ba293321fe3529c4741f76a/src/DomBuilder/CustomerDirectDebitTransferDomBuilder.php#L202

Cheers

[3frogx]

That sounds weird. What is missing? Is there any rule applicable to the orders missing? So far I can't see any rule. It seems proportionate. There are currently 11 open orders, the first 4 of which will be exported. When there were 10, 3 were exported. There is no special order where it gets stuck.

Yes, we've added the data (required by pain.008.003.02). Seems to be that the data is valid in pain.008.001.02 too as the library explicitly includes the data for this format too:

The bank (Sparkasse) rejected the file. Unfortunately there are no error messages, so I don't know the reason. In this case it was our luck, otherwise we probably wouldn't have noticed that the export is incomplete.

greetings, volker

[dennisnissle]

Ok, so the issue is reproducible? Did you try deactivating all plugins but Woo and Germanized and activated a default theme for testing purposes (some plugins may adjust the order query)? Which order statuses do these orders have?

The bank (Sparkasse) rejected the file. Unfortunately there are no error messages, so I don't know the reason.

Ok, maybe you'll need to ask the bank for further details on the issue (there must be some kind of validator available in-house). Does the export file (from a downgraded Germanized version) work as expected?

Cheers

[3frogx]

OK, first some background: Our shop only sells tickets. We use The Event Calendar Pro and Event Tickets Plus solution for this. The cards will only be sent digitally, i.e. not by post. The only payment interface is the direct debit procedure via germanized. Due to the plugin licenses, I don't have a test system and have to carry out all tests in the productive system. It works, but only at night ;-)

Ok, so the issue is reproducible?

Yes. Multiple exports always contain the same orders.

Did you try deactivating all plugins but Woo and Germanized and activated a default theme for testing purposes (some plugins may adjust the order query)?

No, I'll try tonight and report back

Which order statuses do these orders have?

In german "in wartestellung". Some Orders have "in bearbeitung", these were paid for with vouchers. However, I see no connection between the position of the paid and unpaid orders and the content of the export file.

Ok, maybe you'll need to ask the bank for further details on the issue (there must be some kind of validator available in-house).

The validator costs a lot of money, but I have a contact in the bank that I can ask for help

Does the export file (from a downgraded Germanized version) work as expected?

So is a downgrade safe? I'll test that tonight too

Thank you for your patience and help greetings, volker

PS: Yes, I do a backup before testing ;-)

[dennisnissle]

Hi there,

Due to the plugin licenses, I don't have a test system and have to carry out all tests in the productive system. It works, but only at night ;-)

Actually every WP plugin must be licensed under GPL - testing/staging shouldn't be a problem with these extensions. You should really setup a staging environment, it saves a lot of headaches.

Some Orders have "in bearbeitung", these were paid for with vouchers.

Do you use the unpaid only option when exporting orders?

The validator costs a lot of money, but I have a contact in the bank that I can ask for help

Ok, I would appreciate a feedback on the issue.

So is a downgrade safe? I'll test that tonight too

Yes, normally (e.g. minor version downgrades) are safe.

Cheers

[3frogx]

Actually every WP plugin must be licensed under GPL - testing/staging shouldn't be a problem with these extensions. You should really setup a staging environment, it saves a lot of headaches.

Unfortunately, Event Ticket uses its own payment interface in the free version. Communication with woocommerce is only available in the paid version. So no license, no test data.

I disabled all plugins with no change in behavior. After downgrading to 3.6.7 everything worked as expected again.

BUT ...

Do you use the unpaid only option when exporting orders?

was the right question. I finally got it and saw the rule.

The unpaid option itself has no effect on the exported orders, but the date does. I hadn't played with that before.

We never entered anything there. Up to 3.6.7 this means "everything". In 3.6.8 that means "today". If you do not enter a start and end date, only today's orders will be taken into account in the export.

When you finally get it, you ask yourself why you didn't see it straight away ...

I'll take care of the xml schema later.

greetings volker

[3frogx]

I'll take care of the xml schema later.

We are currently taking care of a license for the test software. I'll report as soon as there is something new.

[3frogx]

We finally got our s-firm license which includes a checker for xml files.

Here is the report about the Pain.008.001.02 Export:

Fehler in Zeile 77, Spalte 21 : element 'AdrLine' is not allowed for content model '(Ctry?,AdrLine*)'

<PstlAdr>
       <Ctry>DE</Ctry>
            <AdrLine>xx</AdrLine>
            <AdrLine>xx</AdrLine>
            <AdrLine>xxx</AdrLine>
</PstlAdr> # Line 77

The error is repeated for each entry.

greetings volker

[dennisnissle]

Hi Volker,

this seems to be related to our fix here: https://github.com/vendidero/woocommerce-germanized/commit/a946d98657ae5020ce0375cee8ffb6d7b71fca22

Could you please check that? The commit makes sure that there are no more than 2 AdrLine elements.

Cheers

[3frogx]

As mentioned above, I don't have a test system and in the live system I didn't want to install the github version right now.

But I modified the XML file and took out the third <AdrLine>. The file is then recognized as valid by s-firm.

The change should solve the problem. Thanks very much!

greetings volker