Respostas no Fórum

Visualizando 4 respostas - 1 até 4 (de um total de 4)
  • Fórum: Plugins
    Em resposta a: Peso Cúbico e Peso Bruto

    Oi Ralden, depois de quebrar um bocado a cabeça tentando ler o código e fazendo experimentações enquanto observava o log do Woocommerce Correios, consegui entender a ideia por trás daquela função.

    Depois de fazer vários testes, observei que pode ter uma melhoria no código (na situação de largura e altura ficando maiores do que o comprimento). Seria apenas verificar quando largura e altura forem maiores do que o comprimento, obter a raiz cúbica da cubagem total e aplicá-la às 3 medidas. Com isso, evitaria a cobrança de R$ 79 quando largura e altura passam de 70 cm, se a cubagem virtual puder ser transformada num “cubo” mesmo.

    Fórum: Plugins
    Em resposta a: Peso Cúbico e Peso Bruto
    bugfinder

    (@bugfinder)

    Deste assunto eu entendo, pois tenho pesquisado sobre informações relativas aos Correios durante todo o ano passado. Até Março de 2018 os Correios usavam 10 Kg como limite para peso cúbico. Isso significa que, se o peso cúbico fosse até 10 Kg, então a cobrança seria feita pelo peso real da encomenda. Porém se o peso cúbico passar de 10 Kg, então a cobrança será feita pelo maior peso (real ou cúbico).

    Depois da mudança, o limite de peso cúbico baixou para 5 Kg, mantendo as mesmas regras. Ou seja, se o peso cúbico for até 5 Kg, o envio será tarifado pelo peso real. Mas se o peso cúbico passar de 5 Kg, valerá o maior dos 2.

    Depois de passar esta informação, aproveito para perguntar aos experientes desenvolvedores em PHP que frequentam este fórum para me esclarecer uma dúvida. Eu já pesquisei e sei que o peso cúbico é calculado da seguinte maneira (medidas em centímetros): A x L x C ÷ 6000 = peso cúbico (em Kg). Porém, analisando o código do plugin WooCommerce Correios em includes\class-wc-correios-package.php tem uma função chamada:

    	protected function get_cubage( $height, $width, $length ) {
    		$cubage     = array();
    		$max_values = $this->get_max_values( $height, $width, $length );
    		$root       = $this->calculate_root( $height, $width, $length, $max_values );
    		$greatest   = array_search( max( $max_values ), $max_values, true );
    
    		switch ( $greatest ) {
    			case 'height' :
    				$cubage = array(
    					'height' => max( $height ),
    					'width'  => $root,
    					'length' => $root,
    				);
    				break;
    			case 'width' :
    				$cubage = array(
    					'height' => $root,
    					'width'  => max( $width ),
    					'length' => $root,
    				);
    				break;
    			case 'length' :
    				$cubage = array(
    					'height' => $root,
    					'width'  => $root,
    					'length' => max( $length ),
    				);
    				break;
    
    			default :
    				$cubage = array(
    					'height' => 0,
    					'width'  => 0,
    					'length' => 0,
    				);
    				break;
    		}
    

    Não entendi por que motivo raiz quadrada é usada nesta função, quando já é determinado que basta multiplicar as 3 dimensões em centímetros e dividir por 6000 para se obter o peso cúbico em Kg.

    Eu fiquei receoso de perguntar isto diretamente ao desenvolvedor, pois muita gente diz que ele não tem paciência com novatos e nem sempre responde de maneira amigável.

    Criador do tópico bugfinder

    (@bugfinder)

    A propósito, quais são os serviços que os Correios restringiram para quem tem contrato? Como eu tenho contrato, não houve qualquer mudança para mim, por isso não fiquei sabendo de restrições impostas a quem não tem.

    Criador do tópico bugfinder

    (@bugfinder)

    Oi Ralden,

    Obrigado por me esclarecer sobre GPL e obrigações de quem faz uso de software baseado nesta licença. Então agora eu preciso explicar melhor o que eu quero fazer e de que forma o plugin que tenho em mente vai trabalhar.

    Eu me equivoquei, quando escrevi perguntando se poderia pedir a um programador que use o mesmo código base do plugin desenvolvido pelo Claudio Sanches. Para ser exato, eu só preciso que o painel administrativo seja parecido, ou seja, tenha as mesmas opções (se possível, na mesma ordem) e mais algumas configurações referentes ao meu plugin. A ideia é que o painel pareça familiar a quem já faz uso deste plugin tão popular.

    Reconheço que não sou programador PHP nem de qualquer outra linguagem usada na web. As únicas linguagens que domino (pouco) são QBASIC e Assembly de microprocessadores de 8 e 16 bits, que aprendi sozinho na adolescência nos anos 1980. Hoje estas habilidades não servem de muita coisa, mas ao menos me permitem entender que é possível fazer um painel igual ao do plugin existente, porém usando código diferente. É claro que para oferecer opções iguais, o código seria similar em vários aspectos, porém não necessariamente igual.

    Sobre a questão da monetização, eu compreendi bem as situações que me explicou. Pessoas são complicadas mesmo, eu sei como é isso. Entendo a frustração de quem faz software e o disponibiliza de graça, depois vem gente reclamando que não funciona direito. Por outro lado, também entendo o sentimento de quem pega software gratuito, esperando que funcione como deve. “Pra que essa porcaria que não funciona?” é o que alguns mais exaltados perguntam.

    Especificamente sobre plugins que acessam o webservice dos Correios, tem aquela questão de quando os Correios fazem alguma mudança que compromete o funcionamento do plugin. E isso nem todo mundo leva em conta, querendo que o desenvolvedor conserte logo a droga do software grátis que ele fez. Gente chata e sem noção faz parte do negócio, infelizmente.

    O plugin que tenho em mente trabalhará com apenas 3 métodos de entrega: Carta, PAC e SEDEX, que são os mais usados por lojistas. Uma tabela de frete offline não pode oferecer SEDEX 10, 12 e Hoje, porque a lista de CEPs de origem e destino válidos muda constantemente. Impressos nem podem ser usados para envio de compras (talvez para livros) e as opções internacionais também são pouco usadas. De forma que decidi limitar aos 3 principais métodos para envio, que eu acredito, devam atender mais de 95% das lojas online que entregam apenas no Brasil.

    A mecânica do plugin que eu tenho em mente não fará uso do webservice para obtenção de preços. Todos os valores serão calculados por um algoritmo interno, baseado em tabelas que somam meros 234 KB. A única dependência do webservice será para obtenção de prazos de entrega, que também não podem ser armazenados em tabela offline, uma vez que mudam diariamente. Instruí o programador a incluir no código um timeout na função que aguarda pela resposta de prazos. Se a resposta do webservice demorar, então o plugin prosseguirá apenas com os preços dos envios e apresentará uma mensagem que não foi possível obter prazos de entrega. Até mesmo o link que vai obter do webservice os prazos estará disponível no painel. Caso haja alguma mudança, o próprio lojista poderá copiar e colar o novo link diretamente no painel.

    Estou sendo cauteloso e tentando pensar no máximo de possibilidades que conseguir, para dar liberdade ao lojista de resolver problemas por conta própria. Antes de começar a fazer qualquer cobrança, seja pelo uso do plugin, seja pelos dados que ele usará, eu conduzirei um período de testes com lojistas que desejem experimentar esta solução. Pretendo sanar todos os possíveis erros antes de colocar no mercado o meu plugin, que acredito será uma adição interessante ao WooCommerce.

Visualizando 4 respostas - 1 até 4 (de um total de 4)