there is a filter you could use

$surcharges = apply_filters('wppizza_filter_surcharges', $surcharges, $session, $options, $module);

(you probably do not need the 4th parameter and perhaps not even the third)
so something like

add_filter('wppizza_filter_surcharges', 'my_surcharges', 10, 2);
function my_surcharges($surcharges, $session){

/* 
do your calculations based on time, and whats in the cart (i.e $session) 
and return appropriate surcharges 
*/

return $surcharges;
}

sorry, I cannot advise you on your particular printer as I know nothing about it.

I *do* know however that people use cloudprint with this *type* of printer (but perhaps from different manufactures – have a search here and you might find some ideas )

the plugin just sends things to google cloudprint which in turn sends it to your printer
how your printer then interprets things it was sent by google i have no control over .

might be worth having a chat with the manufacturer of your printer and/or also adjusting the print template you are using (perhaps just a simple 50% fontsize or body width or something in the css settings of that template might work in your scenario)

Hi
this extension would let you do that
https://support.wp-pizza.com/downloads/wppizza-delivery-by-postcode/

kind regards

not to my knowledge

Hi

this is a bug in non-english settings i need to fix – thanks for reminding me

in the meantime, you can work around this by either – temporarily – switching the admin to english and enter the dates then , or simply type the dates in english if your language would change the month

i.e in spanish it would be 17-Ene-2017 for the 17th of January, just enter it as 17-Jan-2017 and it should work (for some months you might not have to change anything if your language has the same 3 letter abbreviation for a month)

>But the calculation of the system is wrong.
no, it isn’t.

42 with taxes included at 8%

42/108*8 = 3.1111… (rounded up as it’s tax) == 3.12

in reverse
38.8888888….+8% = 42

cant comment without a link

says it all there
Protocol “https” not supported or disabled in libcurl

(if the plugin did not support ssl/https it would not work for anyone, which simply is not the case)

the issue is that TLS 1.1 is still enabled (which can be disabled in the apache conf)

from the stripe sdk in use in the plugin

// Explicitly set a TLS version for cURL to use now that we’re starting
// to block 1.0 and 1.1 requests.
//
// If users are on OpenSSL >= 1.0.1, we know that they support TLS 1.2,
// so set that explicitly because on some older Linux distros, clients may
// default to TLS 1.0 even when they have TLS 1.2 available.
//
// For users on much older versions of OpenSSL, set a valid range of
// TLS 1.0 to 1.2 (CURL_SSLVERSION_TLSv1). Note that this may result in
// their requests being blocked unless they’re specially flagged into
// being able to use an old TLS version

yup.
its using stripe 3.0.7
whereas wppizza stripe uses 3.20

see also
https://support.stripe.com/questions/how-do-i-upgrade-my-stripe-integration-from-tls-1-0-to-tls-1-2