FAQ - Webservice Integração - Importação de Pedidos

Esta documentação detalha as validações implementadas em cada método em ImportadorPedidos. Em cada seção, as validações são enumeradas e, em seguida, são apresentadas 15 perguntas e respostas frequentes (FAQ) que abordam dúvidas comuns, sempre fazendo referência ao método e à validação correspondente.

1. Método: converterEnderecoUsandoCEP

Validações do método converterEnderecoUsandoCEP

Lista de Pedidos: Verifica se a lista de pedidos não é nula e contém pelo menos um elemento.
Senha da Central: Valida a senha informada da central; se inválida, retorna erro.
Identificação do Cliente: Usa o CPF/CNPJ e senha do cliente para identificar o cliente cadastrado.
CEP do Pedido: Para cada pedido, verifica se o CEP está informado; caso contrário, retorna erro específico para o pedido.
Conversão do Endereço: Utilizado para converter o CEP em latitude, longitude e endereço formatado; se não encontrado, retorna erro.

FAQ – converterEnderecoUsandoCEP

Q1: O que acontece se a lista de pedidos estiver vazia no método converterEnderecoUsandoCEP?
A1: O método retorna um objeto de resultado com sucesso falso e a mensagem “Erro: a lista de pedidos deve conter pelo menos um elemento.”, impedindo a conversão sem pedidos.

Q2: Como o método converterEnderecoUsandoCEP valida a senha da central?
A2: Ele utiliza o DAO da Empresa para validar a senha; se a central não for identificada, retorna erro “Erro: Senha invalida.”.

Q3: O que ocorre se o cliente não for encontrado no método converterEnderecoUsandoCEP?
A3: O método retorna um erro informando que o cliente com o CPF/CNPJ informado não está cadastrado, indicando o formato esperado para o CNPJ.

Q4: Qual a validação aplicada quanto ao CEP em cada pedido?
A4: O método verifica se o CEP foi informado; se estiver ausente, retorna erro indicando “Pedido [número] sem o número do CEP.”

Q5: Como o método trata a conversão do endereço a partir do CEP?
A5: Utiliza o MapaCEPDAO para recuperar um objeto de endereço. Se o endereço não for encontrado, retorna erro especificando que o CEP pesquisado não gerou resultado.

Q6: O método converterEnderecoUsandoCEP permite pedidos sem CEP?
A6: Não; se o CEP estiver vazio para algum pedido, o método interrompe a conversão e retorna a mensagem de erro apropriada.

Q7: Há alguma verificação adicional de formatação ou dados no CEP?
A7: A validação se concentra em verificar se o campo CEP não está vazio, utilizando-o para recuperar dados no MapaCEPDAO.

Q8: Qual é o retorno do método caso todos os pedidos sejam convertidos com sucesso?
A8: Retorna um objeto do tipo ResultadoConversaoEnderecoPeloCEPVO com sucesso verdadeiro e uma mensagem informando quantos pedidos foram convertidos.

Q9: Em caso de exceção durante a conversão, qual é a resposta do método converterEnderecoUsandoCEP?
A9: O método captura a exceção e retorna um objeto de resultado com sucesso falso e a mensagem “Erro inexperado na conversão.”

Q10: O que acontece se a senha da central estiver incorreta?
A10: A validação falha e o método retorna “Erro: Senha invalida.” sem prosseguir para as demais etapas.

Q11: Como é tratado um CEP que não gera resultado no banco de dados?
A11: Se o CEP pesquisado não retornar um endereço, o método lança uma mensagem de erro específica para o pedido em questão.

Q12: Existe validação de formato para o CEP?
A12: A verificação consiste em confirmar que o CEP não está vazio; detalhes de formatação são tratados internamente pelo DAO responsável pela conversão.

Q13: O método converterEnderecoUsandoCEP realiza validações por pedido individualmente?
A13: Sim, cada pedido é validado individualmente quanto à presença do CEP e a conversão do endereço.

Q14: É possível converter apenas alguns pedidos e ignorar os sem CEP?
A14: Não; se qualquer pedido não tiver o CEP informado, o método interrompe e retorna erro para o primeiro pedido sem CEP.

Q15: Quais parâmetros são obrigatórios para a execução do método converterEnderecoUsandoCEP?
A15: São obrigatórios: uma lista de pedidos com pelo menos um elemento, CPF/CNPJ, senha do cliente e senha da central, além de cada pedido conter o CEP informado.

2. Método: importarPedidos

Validações do método importarPedidos

Lista de Pedidos: Verifica se a lista não é nula e contém ao menos um pedido.
Senha da Central: Valida a senha da central; se inválida, retorna erro.
Identificação do Cliente: Valida o CPF/CNPJ e senha do cliente para identificar o cliente.
Ponto de Interesse (POI): Se o pedido requer cadastro de POI, o método chama a função validarPoi para conferir a existência e integridade dos dados do POI.
Loja: Verifica se a loja está informada e se é válida (pelo código ou nome); caso contrário, retorna erro.
Número do Pedido: Confere se o número do pedido não é nulo, não vazio e não duplicado conforme regras de data e loja.
Data e Hora do Pedido: Valida se a data e a hora do pedido estão corretas e se a hora está no formato HH:mm.
Zona e Vendedor: Valida se a zona e o vendedor estão informados e se correspondem a registros válidos.
Coordenadas Geográficas: Verifica se latitude e longitude são numéricas e estão dentro dos limites válidos.
Endereço e Geocoding: Caso não haja coordenadas, o método tenta obter geocoding a partir do endereço; se falhar, retorna erro.
Horários de Entrega: Valida se a hora inicial e final de entrega estão informadas, corretas e se a final não ocorre antes da inicial.
Tempo de Atendimento: Verifica se o tempo de atendimento foi informado e é maior que zero.
Número GSM: Se informado, o número deve estar no formato de celular.
Nota Fiscal, Número de Carregamento e Lote: Verifica o tamanho máximo permitido (até 45 dígitos) para estes campos.
Data e Hora do Compromisso de Entrega: Devem estar informados e no formato adequado.

FAQ – importarPedidos

Q1: O que acontece se a lista de pedidos estiver vazia no método importarPedidos?
A1: O método retorna um ResultadoImportacaoVO com sucesso falso e a mensagem “Erro: a lista de pedidos deve conter pelo menos um elemento.”

Q2: Como o método importarPedidos valida a senha da central?
A2: Ele utiliza o DAO da Empresa para validar a senha; se a central não for encontrada, retorna “Erro: Senha invalida.”

Q3: O que ocorre se o cliente não for identificado?
A3: O método retorna um erro informando que o cliente com o CPF/CNPJ informado não está cadastrado, especificando o formato esperado do CNPJ.

Q4: Como são validados os dados do Ponto de Interesse (POI) no método importarPedidos?
A4: Se o pedido exigir o cadastro do POI, o método chama a função validarPoi, que checa a presença do código, nome, descrição, grupo, raio e, em alguns casos, geocoding ou endereço.

Q5: Qual é a validação para a loja no método importarPedidos?
A5: O método verifica se a loja está informada e se é encontrada (por código ou nome). Caso contrário, retorna erro solicitando o cadastro da loja.

Q6: O que acontece se o número do pedido já estiver cadastrado?
A6: Dependendo da configuração do cliente (por data ou loja), o método retorna um erro informando que o pedido já foi cadastrado.

Q7: Como o método importarPedidos valida a data e hora do pedido?
A7: Verifica se a data e a hora estão informadas e se a hora está no formato HH:mm; se não, retorna erro indicando “Hora do pedido inválida.”

Q8: O que é verificado quanto à zona e ao vendedor do pedido?
A8: O método valida se ambos estão informados e se correspondem a registros válidos no sistema; senão, retorna erro com a mensagem apropriada.

Q9: Quais validações são realizadas nas coordenadas geográficas?
A9: São verificados se latitude e longitude estão preenchidos, se podem ser convertidos para números e se estão dentro dos limites (latitude entre –90 e 90 e longitude entre –180 e 180).

Q10: Como o método trata pedidos sem coordenadas mas com endereço?
A10: O método tenta obter o geocoding usando o endereço (e, em alguns casos, pelo CEP) para preencher latitude e longitude; se não conseguir, retorna erro.

Q11: Como são validados os horários de entrega?
A11: Verifica se a hora inicial e final de entrega estão informadas, no formato correto e que a hora final não seja anterior à hora inicial.

Q12: Qual é a validação aplicada ao tempo de atendimento?
A12: O tempo de atendimento deve ser maior que zero; caso contrário, o método retorna erro indicando a necessidade de informar esse dado.

Q13: O número GSM é validado?
A13: Sim, se o número GSM estiver informado, ele deve estar no formato de um número de celular válido; senão, ocorre erro.

Q14: Como são tratados os campos de Nota Fiscal, Número de Carregamento e Lote?
A14: Cada um desses campos é verificado para que não ultrapasse 45 dígitos; se exceder, o método retorna um erro específico.

Q15: Quais os requisitos para os dados do compromisso de entrega?
A15: É necessário que a data e a hora do compromisso de entrega estejam informadas e que a hora esteja no formato HH:MM, caso contrário, retorna erro.

3. Método: consultarStatusEntregaPedido

Validações do método consultarStatusEntregaPedido

Senha da Central: Validação inicial da senha da central.
Identificação do Cliente: Verifica se o cliente existe com base no CPF/CNPJ e senha.
Consulta de Itinerário: Verifica se há um itinerário associado ao pedido e, se não houver, informa que o pedido nunca foi roteirizado.
Recuperação de Erros: Caso o itinerário seja encontrado, o método recupera os erros associados ao mesmo.

FAQ – consultarStatusEntregaPedido

Q1: O que acontece se a senha da central for inválida no método consultarStatusEntregaPedido?
A1: O método retorna um ResultadoConsultaStatusVO com sucesso falso e a mensagem “Erro: Senha invalida.”

Q2: Como o método valida o cliente?
A2: Ele utiliza o DAO do Cliente para identificar o cliente com CPF/CNPJ e senha; se não encontrar o cliente, retorna erro indicando que o cliente não está cadastrado.

Q3: O que significa se nenhum itinerário for encontrado para o pedido?
A3: A mensagem “Pedido nunca foi roteirizado para entrega” é retornada, indicando que o pedido ainda não passou pelo processo de roteirização.

Q4: Como o método consultarStatusEntregaPedido lida com erros associados ao itinerário?
A4: Após recuperar o itinerário, o método chama uma rotina para recuperar erros e os inclui na resposta.

Q5: É necessário informar todos os parâmetros para consultar o status de entrega?
A5: Sim, é obrigatório informar o pedido, CPF/CNPJ, senha do cliente e senha da central.

Q6: Qual é o tipo de retorno quando o status é consultado com sucesso?
A6: Retorna um objeto ResultadoConsultaStatusVO com sucesso verdadeiro, a mensagem “Pedido encontrado.” e o itinerário de viagem.

Q7: O que ocorre se ocorrer uma exceção durante a consulta do status?
A7: O método captura a exceção, registra o erro e retorna um ResultadoConsultaStatusVO com sucesso falso e uma mensagem genérica de erro.

Q8: Posso consultar o status de qualquer pedido?
A8: Sim, desde que o pedido possua um registro de itinerário ou erros de roteirização no sistema.

Q9: Como o método trata a conexão com o banco?
A9: Ele obtém uma nova conexão por meio do FabricaConexao para cada operação de validação e consulta.

Q10: Qual a importância do itinerário na consulta do status de entrega?
A10: O itinerário contém o histórico de status e erros que permitem identificar o estágio atual do pedido na entrega.

Q11: O que é necessário para que a consulta retorne “Pedido encontrado.”?
A11: É necessário que exista um itinerário previamente cadastrado para o pedido e que a conexão e validação dos dados tenham sido bem-sucedidas.

Q12: Como é validada a conexão com o banco de dados no método?
A12: O método utiliza o FabricaConexao para obter a conexão, assegurando que cada chamada aos DAOs possua conexão ativa.

Q13: Existe alguma validação específica do objeto “pedido”?
A13: A validação se concentra na existência do itinerário relacionado ao pedido; os dados do pedido já devem estar previamente validados na etapa de importação.

Q14: O método pode retornar informações parciais em caso de erro?
A14: Não; se ocorrer qualquer falha na validação ou consulta, o método retorna um objeto de resultado com sucesso falso e mensagem de erro.

Q15: Quais parâmetros devo conferir se a consulta não retornar o status esperado?
A15: Verifique se o CPF/CNPJ, senha do cliente, senha da central e os dados do pedido estão corretos, pois qualquer inconsistência impedirá a consulta do itinerário.

4. Método: listarItinerariosCarregamento

Validações do método listarItinerariosCarregamento

Senha da Central: Verifica se a senha da central é válida.
Identificação do Cliente: Confirma a existência do cliente com os dados fornecidos.
Recuperação da Lista: Utiliza o DAO de Itinerário para recuperar a lista de itinerários com base no número de carregamento.

FAQ – listarItinerariosCarregamento

Q1: Quais parâmetros são obrigatórios no método listarItinerariosCarregamento?
A1: É necessário informar o número do carregamento, CPF/CNPJ, senha do cliente e senha da central.

Q2: O que acontece se a senha da central for inválida?
A2: O método retorna um ResultadoConsultaListaItinerariosVO com sucesso falso e a mensagem “Erro: Senha invalida.”

Q3: Como o método identifica o cliente?
A3: Utiliza o DAO do Cliente para validar o CPF/CNPJ e senha; se o cliente não for encontrado, retorna o erro correspondente.

Q4: Qual é o critério de busca para os itinerários?
A4: A busca é feita pelo número do carregamento associado aos pedidos.

Q5: O que ocorre se nenhum itinerário for encontrado para o carregamento?
A5: O método retorna uma lista vazia com uma mensagem de sucesso indicando que a lista foi recuperada, mas o usuário pode interpretar que não há itinerários cadastrados.

Q6: Posso utilizar o método para buscar itinerários de vários carregamentos?
A6: Este método foi projetado para filtrar por um único número de carregamento.

Q7: Como é tratada a conexão com o banco?
A7: O método obtém a conexão por meio do FabricaConexao e a repassa para os DAOs utilizados.

Q8: Existe tratamento de exceções no método?
A8: Sim, se ocorrer alguma exceção, o método captura o erro e retorna uma mensagem genérica de falha na consulta dos itinerários.

Q9: O que o método retorna em caso de sucesso?
A9: Um objeto ResultadoConsultaListaItinerariosVO com sucesso verdadeiro, uma mensagem de sucesso e a lista de itinerários encontrados.

Q10: É possível que a lista de itinerários contenha erros?
A10: A função se preocupa em recuperar a lista; a eventual existência de erros nos itinerários é tratada em métodos complementares de recuperação.

Q11: Quais tipos de itinerários são listados?
A11: São listados itinerários associados ao número de carregamento informado e pertencentes ao cliente autenticado.

Q12: O método realiza alguma validação sobre o formato do número de carregamento?
A12: A validação principal é a existência do número; detalhes adicionais devem estar conformes ao cadastro do cliente.

Q13: Como é informado o usuário se não houver itinerários?
A13: A mensagem de retorno será “Lista de Itinerarios recuperada com sucesso.”, porém a lista estará vazia.

Q14: Existe limite para o número de itinerários retornados?
A14: Não há um limite explícito; todos os itinerários correspondentes são retornados.

Q15: Quais DAOs são utilizados na execução deste método?
A15: São utilizados o DAO da Empresa para validação, o DAO do Cliente para identificação e o DAO de Itinerário para a recuperação dos itinerários.

5. Método: listarItinerariosLote

Validações do método listarItinerariosLote

Senha da Central: Verifica se a senha da central está correta.
Identificação do Cliente: Confirma se o cliente existe.
Busca pelo Lote: Recupera a lista de itinerários com base no número do lote.
Validação de Lista Vazia: Se a lista estiver vazia, atualiza a mensagem informando “Nenhuma roteirização ou itinerário encontrado.”

FAQ – listarItinerariosLote

Q1: Quais dados são necessários para executar o método listarItinerariosLote?
A1: É necessário informar o número do lote, CPF/CNPJ, senha do cliente e senha da central.

Q2: Como o método trata a senha da central?
A2: Valida a senha utilizando o DAO da Empresa; se inválida, retorna “Erro: Senha invalida.”

Q3: O que acontece se o cliente não for identificado?
A3: O método retorna um erro informando que o cliente não está cadastrado.

Q4: Como é realizada a busca dos itinerários por lote?
A4: Através do DAO de Itinerário, filtrando pelo número do lote e associado ao cliente autenticado.

Q5: Qual é a mensagem retornada se nenhum itinerário for encontrado?
A5: A mensagem será “Nenhuma roteirização ou itinerário encontrado.”

Q6: O método retorna um objeto de sucesso mesmo com a lista vazia?
A6: Sim, o objeto é retornado com sucesso verdadeiro, mas com uma mensagem específica e a lista vazia.

Q7: Quais conexões são utilizadas na execução do método?
A7: São utilizadas conexões obtidas via FabricaConexao para todos os DAOs envolvidos.

Q8: Existe validação sobre o formato do número do lote?
A8: A validação se limita a verificar se o número foi informado; o formato deve estar conforme o cadastro do cliente.

Q9: Posso buscar itinerários de lotes parciais?
A9: O método busca por correspondência exata do número do lote informado.

Q10: Qual DAO é responsável por recuperar a lista de itinerários?
A10: O DAO de Itinerário (ItinerarioViagemDAO) é utilizado para essa recuperação.

Q11: O método realiza tratamento de exceções?
A11: Sim, qualquer exceção é capturada e o método retorna uma mensagem de erro genérica.

Q12: É possível filtrar itinerários por mais de um lote neste método?
A12: Este método aceita apenas um número de lote por chamada.

Q13: Como é informado o usuário se a senha estiver incorreta?
A13: Retorna “Erro: Senha invalida.” sem prosseguir com a consulta.

Q14: O que fazer se a lista de itinerários estiver vazia?
A14: O usuário deverá verificar se o número do lote está correto ou se há itinerários cadastrados para aquele lote.

Q15: Quais são os principais DAOs utilizados neste método?
A15: São utilizados os DAOs da Empresa, Cliente e ItinerarioViagem.

6. Método: listarItinerariosRoterizado

Validações do método listarItinerariosRoterizado

Senha da Central: Valida a senha informada.
Identificação do Cliente: Confirma se o cliente está cadastrado.
Verificação da Viagem: Verifica se existe uma viagem com o ID informado para o cliente.
Recuperação dos Itinerários: Utiliza o DAO de Itinerário para recuperar a lista com base na viagem.
Recuperação de Erros: Chama a rotina para atualizar a lista de ocorrências (erros) para cada itinerário.

FAQ – listarItinerariosRoterizado

Q1: Quais parâmetros são obrigatórios no método listarItinerariosRoterizado?
A1: É necessário informar o ID da viagem, CPF/CNPJ, senha do cliente e senha da central.

Q2: O que acontece se a senha da central for inválida?
A2: O método retorna um ResultadoConsultaListaItinerariosVO com sucesso falso e a mensagem “Erro: Senha invalida.”

Q3: Como o método valida a existência da viagem?
A3: Ele utiliza o DAO de Viagem para recuperar a viagem com o ID informado; se não existir, retorna erro “Erro: Nao existe viagem com o identificador informado.”

Q4: O que é retornado se a viagem for encontrada?
A4: Retorna uma lista de itinerários associados à viagem e, se houver ocorrências, estas são recuperadas e associadas a cada itinerário.

Q5: Como é tratada a conexão com o banco?
A5: São utilizadas conexões obtidas via FabricaConexao para cada operação de validação e recuperação.

Q6: O que ocorre se o cliente não for identificado?
A6: O método retorna erro informando que o cliente não está cadastrado.

Q7: Qual DAO é responsável por recuperar os itinerários?
A7: O ItinerarioViagemDAO é o responsável pela recuperação dos itinerários.

Q8: Como são atualizados os erros associados aos itinerários?
A8: Para cada itinerário, o método chama a função de recuperação de erros e atualiza a lista de ocorrências.

Q9: Existe algum limite para o número de itinerários retornados?
A9: Não há limite explícito; todos os itinerários associados à viagem são retornados.

Q10: O que acontece se ocorrer uma exceção durante a recuperação?
A10: A exceção é capturada, o erro é logado e o método retorna um objeto de resultado com sucesso falso e mensagem genérica de erro.

Q11: O método pode ser usado para consultar itinerários de viagens finalizadas?
A11: Sim, contanto que o ID da viagem esteja corretamente informado e associada ao cliente.

Q12: Há alguma validação específica do formato do ID da viagem?
A12: A validação principal é a existência da viagem para o cliente; o formato do ID deve estar conforme o cadastro no sistema.

Q13: Como saber se a consulta foi realizada com sucesso?
A13: O objeto retornado terá o campo “sucesso” verdadeiro e uma mensagem “Lista de Itinerarios recuperada com sucesso.”

Q14: Quais informações adicionais podem ser encontradas nos itinerários?
A14: Além dos dados do pedido, os itinerários podem conter a lista de ocorrências (erros) associadas.

Q15: É necessário tratar manualmente os erros de itinerários após a consulta?
A15: Não; o método já recupera e associa os erros a cada itinerário automaticamente.

7. Método: listarPoIRoterizado

Validações do método listarPoIRoterizado

Senha da Central: Valida a senha informada.
Identificação do Cliente: Confirma se o cliente está cadastrado.
Verificação da Viagem: Confirma a existência da viagem com o ID informado.
Recuperação dos Itinerários: Obtém os itinerários da viagem.
Extração de POIs: A partir dos itinerários, extrai os pontos de interesse (POI) sem repetições.

FAQ – listarPoIRoterizado

Q1: Quais parâmetros são necessários para o método listarPoIRoterizado?
A1: É preciso informar o ID da viagem, CPF/CNPJ, senha do cliente e senha da central.

Q2: O que acontece se a senha da central for inválida?
A2: O método retorna um ResultadoConsultaListaPoIRoteirizadosVO com sucesso falso e a mensagem “Erro: Senha invalida.”

Q3: Como o método valida a existência da viagem?
A3: Utiliza o DAO de Viagem para recuperar a viagem com o ID informado; se não for encontrada, retorna erro.

Q4: Como são extraídos os POIs dos itinerários?
A4: O método percorre a lista de itinerários e, para cada novo POI (não repetido), adiciona-o à lista final.

Q5: O que é retornado se nenhum POI for encontrado?
A5: Se a lista de itinerários estiver vazia ou não houver POIs distintos, a lista retornada ficará vazia.

Q6: Qual é a importância do campo “idPontoInteresse” nesta consulta?
A6: Ele é utilizado para identificar e evitar a duplicação dos pontos de interesse na lista final.

Q7: O que ocorre se o cliente não for identificado?
A7: O método retorna erro informando que o cliente não está cadastrado.

Q8: Existe alguma validação adicional quanto aos dados dos itinerários?
A8: A validação foca na existência dos itinerários e na extração única dos POIs.

Q9: Como é tratada a conexão com o banco neste método?
A9: A conexão é obtida via FabricaConexao e utilizada nos DAOs de Empresa, Cliente e Viagem.

Q10: Quais mensagens de erro podem ser retornadas neste método?
A10: Podem ocorrer mensagens “Erro: Senha invalida.”, “Erro: cliente com CPF/CNPJ ... nao cadastrado.” ou “Erro: Nao existe viagem com o identificador informado.”

Q11: Posso usar este método para verificar se um POI já foi roteirizado?
A11: Sim, ele retorna os pontos de interesse que já foram associados a itinerários de uma viagem.

Q12: O método lida com duplicatas de POI?
A12: Sim, a lógica compara o ID dos POIs para garantir que cada ponto seja listado apenas uma vez.

Q13: Qual DAO é utilizado para recuperar os itinerários?
A13: O ItinerarioViagemDAO é utilizado para obter a lista de itinerários.

Q14: O método retorna informações adicionais sobre cada POI?
A14: Retorna os dados básicos do POI, como o ID e o código, conforme extraídos dos itinerários.

Q15: Como saber se a operação foi realizada com sucesso?
A15: O objeto retornado terá o campo “sucesso” verdadeiro e a mensagem “Lista de Pontos de Interesse recuperada com sucesso.”

8. Método: listarPedidosPorStatus

Validações do método listarPedidosPorStatus

Senha da Central: Verifica se a senha informada é válida.
Identificação do Cliente: Confirma se o cliente está cadastrado.
Filtragem por Status: Utiliza o DAO de Pedidos para recuperar a lista de pedidos com o status informado.

FAQ – listarPedidosPorStatus

Q1: Quais parâmetros são obrigatórios no método listarPedidosPorStatus?
A1: É necessário informar o status do pedido, CPF/CNPJ, senha do cliente e senha da central.

Q2: Como é validada a senha da central?
A2: Através do DAO da Empresa; se inválida, retorna “Erro: Senha invalida.”

Q3: O que acontece se o cliente não for identificado?
A3: O método retorna erro informando que o cliente com o CPF/CNPJ informado não está cadastrado.

Q4: Qual é o critério de filtragem para os pedidos?
A4: A filtragem é feita com base no status do pedido (por exemplo, VENDA_FINALIZADA).

Q5: O método pode retornar uma lista vazia?
A5: Sim, se nenhum pedido corresponder ao status informado, a lista retornada ficará vazia.

Q6: Qual DAO é utilizado para recuperar os pedidos?
A6: O método utiliza o PedidosRotasDAO para listar os pedidos conforme o status.

Q7: Existe tratamento para exceções durante a consulta?
A7: Sim, exceções são capturadas e o método retorna um resultado com sucesso falso e uma mensagem de erro.

Q8: Como é informado o usuário se a operação for bem-sucedida?
A8: O método retorna um objeto com sucesso verdadeiro e a mensagem “Lista de Pedidos recuperada com sucesso.”

Q9: O status informado é case sensitive?
A9: O status deve ser informado conforme definido na enumeração StatusPedido do sistema.

Q10: É possível filtrar pedidos por múltiplos status com este método?
A10: Este método aceita apenas um status por chamada.

Q11: Como o método lida com conexões ao banco?
A11: Ele obtém conexões via FabricaConexao para os DAOs de Empresa, Cliente e Pedidos.

Q12: Posso usar este método para monitorar o andamento dos pedidos?
A12: Sim, ele é ideal para recuperar pedidos em um status específico e monitorar sua evolução.

Q13: O que devo fazer se nenhum pedido for retornado?
A13: Verifique se o status informado está correto e se há pedidos cadastrados com aquele status.

Q14: Qual a utilidade deste método para o cliente?
A14: Ele permite ao cliente acompanhar a situação dos seus pedidos, filtrando por status como “VENDA_FINALIZADA”, entre outros.

Q15: Quais são os possíveis status que podem ser consultados?
A15: Os status são definidos na enumeração StatusPedido e podem incluir VENDA_FINALIZADA, LIBERADO_PARA_SEPARACAO, NAO_ENTREGUE, etc.

9. Método: alterarStatusVendaFinalizadoParaLiberadoSeparacao

Validações do método alterarStatusVendaFinalizadoParaLiberadoSeparacao

Validação de Acesso: Verifica se a senha da central e os dados do cliente estão corretos.
Status Atual: Confirma que o status do pedido está como VENDA_FINALIZADA.
Chamada à Fachada: Encaminha a alteração de status para o GerenciadorPedidosFachada, que realiza as validações internas.

FAQ – alterarStatusVendaFinalizadoParaLiberadoSeparacao

Q1: Quais parâmetros são obrigatórios no método alterarStatusVendaFinalizadoParaLiberadoSeparacao?
A1: É preciso informar a lista de pedidos, CPF/CNPJ, senha do cliente e senha da central.

Q2: O que acontece se a senha da central for inválida?
A2: O método retorna um ResultadoAlteracaoStatusPedidosVO com sucesso falso e a mensagem “Erro: Senha invalida.”

Q3: Como é verificado o status atual do pedido?
A3: A validação é realizada internamente pelo GerenciadorPedidosFachada, que confirma que o status atual é VENDA_FINALIZADA.

Q4: Qual o novo status aplicado pelo método?
A4: O método altera o status de VENDA_FINALIZADA para LIBERADO_PARA_SEPARACAO.

Q5: O que ocorre se o pedido não estiver com o status VENDA_FINALIZADA?
A5: O GerenciadorPedidosFachada deverá identificar a inconsistência e retornar um erro apropriado.

Q6: O método altera o status de todos os pedidos da lista?
A6: Sim, todos os pedidos contidos na lista que estiverem com o status correto serão alterados.

Q7: Quais validações de acesso são realizadas?
A7: São validados a senha da central e a identificação do cliente, conforme nos métodos anteriores.

Q8: Se ocorrer um erro na alteração, qual é a mensagem retornada?
A8: Em caso de exceção, o método retorna “Erro geral : alterarStatusVendaFinalizadoParaLiberadoSeparacao.”

Q9: O método realiza alterações parciais ou tudo ou nada?
A9: A alteração é realizada para todos os pedidos que cumpram a validação; se houver erro em algum, geralmente a transação é abortada.

Q10: Como o GerenciadorPedidosFachada é utilizado neste método?
A10: Ele é instanciado e chamado para executar a alteração do status, centralizando a lógica de negócios.

Q11: Existe alguma validação quanto à lista de pedidos?
A11: Sim, a lista não pode ser nula e deve conter pelo menos um pedido.

Q12: Posso usar este método para alterar pedidos com status diferente?
A12: Não, este método é específico para alterar de VENDA_FINALIZADA para LIBERADO_PARA_SEPARACAO.

Q13: Quais DAOs são invocados durante a alteração?
A13: A alteração é realizada pela fachada (GerenciadorPedidosFachada), que internamente utiliza os DAOs de pedidos.

Q14: Qual é o retorno esperado em caso de sucesso?
A14: Um ResultadoAlteracaoStatusPedidosVO com sucesso verdadeiro e mensagem confirmando a atualização do status.

Q15: É possível acompanhar quais pedidos foram alterados?
A15: O retorno inclui informações sobre a quantidade de pedidos atualizados, permitindo a verificação da operação.

10. Método: alterarStatusLiberadoSeparacaParaEmSeparacao

Validações do método alterarStatusLiberadoSeparacaParaEmSeparacao

Acesso e Cliente: Valida senha da central e identificação do cliente.
Status Atual: Confirma que o status atual é LIBERADO_PARA_SEPARACAO.
Parametro Compromisso: Verifica se o parâmetro compromissoSeparacao foi informado corretamente.
Chamada à Fachada: Encaminha a alteração para o GerenciadorPedidosFachada, que realiza a mudança para EM_SEPARACAO.

FAQ – alterarStatusLiberadoSeparacaParaEmSeparacao

Q1: Quais parâmetros são obrigatórios no método alterarStatusLiberadoSeparacaParaEmSeparacao?
A1: São necessários a lista de pedidos, o compromisso de separação, CPF/CNPJ, senha do cliente e senha da central.

Q2: O que acontece se o parâmetro compromissoSeparacao estiver ausente?
A2: O método pode retornar erro ou falhar na alteração, pois esse parâmetro é necessário para a alteração de status.

Q3: Qual o status atual exigido para a alteração neste método?
A3: Os pedidos devem estar com o status LIBERADO_PARA_SEPARACAO.

Q4: Qual o novo status que será aplicado?
A4: O status dos pedidos será alterado para EM_SEPARACAO.

Q5: Como é verificada a senha da central?
A5: Por meio do DAO da Empresa; se inválida, o método retorna “Erro: Senha invalida.”

Q6: O que acontece se o cliente não for identificado?
A6: O método retorna erro informando que o cliente não está cadastrado.

Q7: A alteração é realizada individualmente para cada pedido?
A7: Sim, a alteração é aplicada a cada pedido na lista que passar nas validações.

Q8: Como o GerenciadorPedidosFachada atua neste método?
A8: Ele recebe os parâmetros e efetua a alteração de status, realizando as validações internas necessárias.

Q9: O que acontece se algum pedido não estiver no status esperado?
A9: O GerenciadorPedidosFachada deverá retornar um erro para o(s) pedido(s) que não atenderem ao status atual exigido.

Q10: Qual é o retorno do método em caso de sucesso?
A10: Um objeto ResultadoAlteracaoStatusPedidosVO com sucesso verdadeiro e uma mensagem informando a alteração para EM_SEPARACAO.

Q11: Como é tratada uma exceção durante o processo?
A11: Se ocorrer uma exceção, o método captura o erro e retorna “Erro geral : alterarStatusLiberadoSeparacaParaEmSeparacao.”

Q12: O método permite alterar apenas pedidos com status LIBERADO_PARA_SEPARACAO?
A12: Sim, a alteração só ocorre se o status atual for o esperado.

Q13: Quais validações de acesso são realizadas?
A13: São verificadas a senha da central e a existência do cliente com base nos dados fornecidos.

Q14: Posso usar este método para alterar pedidos sem compromisso de separação?
A14: Não, o parâmetro compromissoSeparacao é obrigatório para a transição para EM_SEPARACAO.

Q15: Onde posso acompanhar os pedidos atualizados?
A15: O retorno do método informa quantos pedidos foram atualizados, permitindo a verificação da operação.

11. Método: alterarStatusEmSeparacaoParaSeparados

Validações do método alterarStatusEmSeparacaoParaSeparados

Acesso e Cliente: Valida a senha da central e identifica o cliente.
Status Atual: Verifica se o status atual é EM_SEPARACAO.
Chamada à Fachada: Encaminha para o GerenciadorPedidosFachada para alterar o status para SEPARADOS.

FAQ – alterarStatusEmSeparacaoParaSeparados

Q1: Quais parâmetros são obrigatórios no método alterarStatusEmSeparacaoParaSeparados?
A1: É necessário informar a lista de pedidos, CPF/CNPJ, senha do cliente e senha da central.

Q2: Qual o status esperado dos pedidos para esta alteração?
A2: Os pedidos devem estar no status EM_SEPARACAO.

Q3: Qual o novo status aplicado por este método?
A3: O status será alterado para SEPARADOS.

Q4: Como é validada a senha da central?
A4: Através do DAO da Empresa; se a senha for inválida, retorna “Erro: Senha invalida.”

Q5: O que ocorre se o cliente não for encontrado?
A5: O método retorna erro informando que o cliente não está cadastrado.

Q6: Como a alteração de status é processada?
A6: O GerenciadorPedidosFachada realiza a alteração após confirmar que os pedidos estão com o status EM_SEPARACAO.

Q7: É possível que apenas alguns pedidos sejam alterados?
A7: A alteração é aplicada a todos os pedidos que cumpram as validações; caso algum não esteja no status correto, a transação poderá ser abortada.

Q8: Qual é o retorno em caso de sucesso?
A8: Retorna um ResultadoAlteracaoStatusPedidosVO com sucesso verdadeiro e uma mensagem confirmando a alteração para SEPARADOS.

Q9: O método trata exceções?
A9: Sim, exceções são capturadas e o método retorna “Erro geral : alterarStatusEmSeparacaoParaSeparados.”

Q10: É possível alterar o status se o pedido não estiver em EM_SEPARACAO?
A10: Não, o método só altera pedidos que estejam no status EM_SEPARACAO.

Q11: Quais DAOs são invocados na alteração?
A11: A operação é realizada internamente pelo GerenciadorPedidosFachada, que utiliza os DAOs de pedidos.

Q12: Há alguma validação sobre a lista de pedidos?
A12: Sim, a lista deve conter pelo menos um pedido, caso contrário, a operação não é realizada.

Q13: Como é informada a quantidade de pedidos atualizados?
A13: O retorno do método inclui a quantidade de pedidos que tiveram o status alterado.

Q14: O que devo fazer se a alteração não ocorrer?
A14: Verifique se os pedidos estão no status correto e se os parâmetros de acesso (senha, CPF/CNPJ) estão corretos.

Q15: Posso usar este método para monitorar a separação dos pedidos?
A15: Sim, ele é utilizado para marcar os pedidos que passaram da etapa de separação para o status SEPARADOS.

12. Método: alterarStatusSeparadosParaLiberadosRoteirizacao

Validações do método alterarStatusSeparadosParaLiberadosRoteirizacao

Acesso e Cliente: Verifica senha da central e identificação do cliente.
Status Atual: Confirma que os pedidos estão com status SEPARADOS.
Chamada à Fachada: Encaminha para o GerenciadorPedidosFachada que altera o status para LIBERADOS_PARA_ROTEIRIZACAO.

FAQ – alterarStatusSeparadosParaLiberadosRoteirizacao

Q1: Quais parâmetros são obrigatórios no método alterarStatusSeparadosParaLiberadosRoteirizacao?
A1: É necessário informar a lista de pedidos, CPF/CNPJ, senha do cliente e senha da central.

Q2: Qual o status atual exigido para esta alteração?
A2: Os pedidos devem estar no status SEPARADOS.

Q3: Qual o novo status aplicado?
A3: O status será alterado para LIBERADOS_PARA_ROTEIRIZACAO.

Q4: Como é validada a senha da central?
A4: A senha é verificada via DAO da Empresa; se estiver incorreta, retorna “Erro: Senha invalida.”

Q5: O que ocorre se o cliente não for identificado?
A5: Retorna erro informando que o cliente não está cadastrado.

Q6: Como é executada a alteração de status?
A6: Por meio do GerenciadorPedidosFachada, que valida o status atual e efetua a mudança.

Q7: O método processa todos os pedidos da lista?
A7: Sim, desde que todos os pedidos estejam no status SEPARADOS.

Q8: Qual é o retorno em caso de sucesso?
A8: Um objeto ResultadoAlteracaoStatusPedidosVO com sucesso verdadeiro e mensagem informando a alteração.

Q9: E se algum pedido não estiver no status SEPARADOS?
A9: A alteração não será efetuada para aquele pedido e o método poderá retornar erro para a transação.

Q10: Como são tratadas exceções?
A10: Exceções são capturadas e o método retorna “Erro geral : alterarStatusSeparadosParaLiberadosRoteirizacao.”

Q11: O método altera o status individualmente ou em lote?
A11: A alteração é aplicada em lote a todos os pedidos que cumpram as condições.

Q12: Posso reexecutar o método caso a alteração falhe?
A12: Sim, desde que os pedidos estejam novamente com o status SEPARADOS e os parâmetros de acesso estejam corretos.

Q13: Quais DAOs são utilizados durante a operação?
A13: A operação é realizada pela fachada que utiliza internamente os DAOs relacionados aos pedidos.

Q14: Como posso confirmar a quantidade de pedidos alterados?
A14: O retorno do método informa quantos pedidos tiveram seu status atualizado.

Q15: Este método pode ser usado para integrar com outros sistemas de roteirização?
A15: Sim, ao liberar os pedidos para roteirização, o sistema permite que outras integrações processem a rota de entrega.

13. Método: alterarStatusNaoEntreguesParaLiberadoSeparacao

Validações do método alterarStatusNaoEntreguesParaLiberadoSeparacao

Acesso e Cliente: Valida a senha da central e identifica o cliente.
Status Atual: Verifica se os pedidos estão com status NAO_ENTREGUE.
Chamada à Fachada: Encaminha para o GerenciadorPedidosFachada, que altera o status para LIBERADO_PARA_SEPARACAO.

FAQ – alterarStatusNaoEntreguesParaLiberadoSeparacao

Q1: Quais parâmetros são necessários no método alterarStatusNaoEntreguesParaLiberadoSeparacao?
A1: É obrigatório informar a lista de pedidos, CPF/CNPJ, senha do cliente e senha da central.

Q2: Qual o status atual exigido para a alteração?
A2: Os pedidos devem estar com o status NAO_ENTREGUE.

Q3: Qual o novo status que será aplicado?
A3: O novo status será LIBERADO_PARA_SEPARACAO.

Q4: Como é validada a senha da central?
A4: Utilizando o DAO da Empresa; se a senha estiver incorreta, retorna “Erro: Senha invalida.”

Q5: O que ocorre se o cliente não for identificado?
A5: O método retorna erro informando que o cliente não está cadastrado.

Q6: Qual é o papel do GerenciadorPedidosFachada neste método?
A6: Ele centraliza a lógica de alteração, validando o status atual e efetuando a mudança.

Q7: Se algum pedido não estiver com status NAO_ENTREGUE, o que acontece?
A7: A alteração só será efetuada para os pedidos que cumpram a condição; os demais gerarão erro.

Q8: Qual o retorno em caso de sucesso?
A8: Um objeto ResultadoAlteracaoStatusPedidosVO com sucesso verdadeiro e mensagem confirmando a atualização.

Q9: Como são tratadas exceções?
A9: Em caso de exceção, o método retorna “Erro geral : alterarStatusNaoEntreguesParaLiberadoSeparacao.”

Q10: A alteração é feita individualmente ou em lote?
A10: A alteração é aplicada em lote para todos os pedidos válidos na lista.

Q11: É possível reexecutar a operação se ocorrer um erro?
A11: Sim, desde que os pedidos estejam corretamente com o status NAO_ENTREGUE e os dados de acesso estejam corretos.

Q12: Quais DAOs são utilizados na alteração?
A12: A alteração é realizada pela fachada, que utiliza os DAOs de pedidos conforme necessário.

Q13: O método permite acompanhar quantos pedidos foram atualizados?
A13: Sim, o retorno inclui a quantidade de pedidos que tiveram seu status alterado.

Q14: Existe alguma verificação especial para a lista de pedidos?
A14: Sim, a lista não pode ser nula e deve conter ao menos um pedido.

Q15: Como posso confirmar se a alteração foi realizada corretamente?
A15: Verifique a mensagem de retorno e a quantidade de pedidos atualizados informados no objeto de resultado.

14. Método: alterarStatusNaoEntreguesParaLiberadoRoteirizacao

Validações do método alterarStatusNaoEntreguesParaLiberadoRoteirizacao

Acesso e Cliente: Valida senha da central e identificação do cliente.
Status Atual: Confirma que os pedidos estão com status NAO_ENTREGUE.
Chamada à Fachada: Encaminha para o GerenciadorPedidosFachada que altera o status para LIBERADOS_PARA_ROTEIRIZACAO.

FAQ – alterarStatusNaoEntreguesParaLiberadoRoteirizacao

Q1: Quais parâmetros são necessários no método alterarStatusNaoEntreguesParaLiberadoRoteirizacao?
A1: É necessário fornecer a lista de pedidos, CPF/CNPJ, senha do cliente e senha da central.

Q2: Qual o status atual exigido para a alteração?
A2: Os pedidos devem estar com o status NAO_ENTREGUE.

Q3: Qual o novo status aplicado por este método?
A3: O status será alterado para LIBERADOS_PARA_ROTEIRIZACAO.

Q4: Como é validada a senha da central?
A4: A senha é validada utilizando o DAO da Empresa; se inválida, retorna “Erro: Senha invalida.”

Q5: O que ocorre se o cliente não for identificado?
A5: O método retorna erro indicando que o cliente não está cadastrado.

Q6: Qual é o papel do GerenciadorPedidosFachada neste processo?
A6: Ele é responsável por validar o status atual e realizar a alteração para LIBERADOS_PARA_ROTEIRIZACAO.

Q7: Se algum pedido não estiver com status NAO_ENTREGUE, o que acontece?
A7: Apenas os pedidos com status NAO_ENTREGUE serão alterados; os demais serão ignorados ou geram erro.

Q8: Qual é o retorno do método em caso de sucesso?
A8: Um objeto ResultadoAlteracaoStatusPedidosVO com sucesso verdadeiro e mensagem confirmando a atualização.

Q9: Como o método lida com exceções?
A9: Se ocorrer uma exceção, o método captura e retorna “Erro geral : alterarStatusNaoEntreguesParaLiberadoRoteirizacao.”

Q10: A operação é aplicada a cada pedido individualmente?
A10: A alteração é feita em lote para todos os pedidos que atendam às condições.

Q11: Quais validações de acesso são realizadas?
A11: São validadas a senha da central e a identificação do cliente.

Q12: O método permite reexecutar a alteração se houver erro?
A12: Sim, desde que os pedidos estejam com o status correto e os parâmetros estejam corretos.

Q13: Quais DAOs são utilizados nesta operação?
A13: A operação é realizada pela fachada, que utiliza internamente os DAOs de pedidos.

Q14: É possível acompanhar quantos pedidos foram atualizados?
A14: Sim, o objeto de resultado informa a quantidade de pedidos alterados.

Q15: Qual a principal diferença entre este método e o anterior de não entregues para separação?
A15: A diferença está no status de destino: este método altera para LIBERADOS_PARA_ROTEIRIZACAO, enquanto o outro altera para LIBERADO_PARA_SEPARACAO.

15. Método: cancelar_LiberadoRoteirizacao

Validações do método cancelar_LiberadoRoteirizacao

Acesso e Cliente: Valida a senha da central e identifica o cliente.
Status Atual: Verifica que os pedidos estão com status LIBERADOS_PARA_ROTEIRIZACAO.
Chamada à Fachada: Chama o GerenciadorPedidosFachada para reverter o status para SEPARADOS.

FAQ – cancelar_LiberadoRoteirizacao

Q1: Quais parâmetros são obrigatórios no método cancelar_LiberadoRoteirizacao?
A1: É necessário fornecer a lista de pedidos, CPF/CNPJ, senha do cliente e senha da central.

Q2: Qual o status atual esperado para cancelar a roteirização?
A2: Os pedidos devem estar com status LIBERADOS_PARA_ROTEIRIZACAO.

Q3: Qual o novo status definido pelo cancelamento?
A3: O status é revertido para SEPARADOS.

Q4: Como é validada a senha da central?
A4: Utilizando o DAO da Empresa; se a senha estiver errada, retorna “Erro: Senha invalida.”

Q5: O que acontece se o cliente não for identificado?
A5: O método retorna erro indicando que o cliente não está cadastrado.

Q6: Qual o papel do GerenciadorPedidosFachada nesta operação?
A6: Ele é chamado para efetuar a alteração de status de LIBERADOS_PARA_ROTEIRIZACAO para SEPARADOS.

Q7: Se algum pedido não estiver no status LIBERADOS_PARA_ROTEIRIZACAO, o que ocorre?
A7: Apenas os pedidos com o status esperado serão alterados; os demais gerarão erro ou serão ignorados.

Q8: Qual é o retorno esperado em caso de sucesso?
A8: Um ResultadoAlteracaoStatusPedidosVO com sucesso verdadeiro e mensagem informando a reversão do status.

Q9: Como são tratadas exceções neste método?
A9: Exceções são capturadas e o método retorna “Erro geral : cancelar_LiberadoRoteirizacao.”

Q10: O método realiza a alteração em lote?
A10: Sim, a alteração é aplicada a todos os pedidos que atendam às condições de status.

Q11: Quais DAOs são envolvidos na alteração?
A11: A operação é realizada pela fachada que utiliza internamente os DAOs de pedidos.

Q12: É possível reexecutar o cancelamento se ocorrer erro?
A12: Sim, contanto que os pedidos estejam novamente no status LIBERADOS_PARA_ROTEIRIZACAO e os parâmetros estejam corretos.

Q13: Como saber quantos pedidos foram afetados?
A13: O objeto de resultado informa a quantidade de pedidos atualizados.

Q14: Existe alguma validação adicional para a lista de pedidos?
A14: A lista não pode ser nula e deve conter pelo menos um pedido, caso contrário a operação não é realizada.

Q15: Para que situação o método cancelar_LiberadoRoteirizacao deve ser usado?
A15: Ele é utilizado para reverter a liberação para roteirização, retornando os pedidos para o status SEPARADOS.

16. Método: cancelar_Separados

Validações do método cancelar_Separados

Acesso e Cliente: Valida a senha da central e identifica o cliente.
Status Atual: Verifica que os pedidos estão com status SEPARADOS.
Chamada à Fachada: Chama o GerenciadorPedidosFachada para alterar o status para EM_SEPARACAO.

FAQ – cancelar_Separados

Q1: Quais parâmetros são obrigatórios no método cancelar_Separados?
A1: É necessário informar a lista de pedidos, CPF/CNPJ, senha do cliente e senha da central.

Q2: Qual o status atual dos pedidos para que o cancelamento seja aplicado?
A2: Os pedidos devem estar com status SEPARADOS.

Q3: Qual novo status é definido ao cancelar a separação?
A3: O status será alterado para EM_SEPARACAO.

Q4: Como é validada a senha da central?
A4: Através do DAO da Empresa; se inválida, retorna “Erro: Senha invalida.”

Q5: O que acontece se o cliente não for identificado?
A5: O método retorna um erro informando que o cliente não está cadastrado.

Q6: Qual é o papel do GerenciadorPedidosFachada neste cancelamento?
A6: Ele processa a alteração de status, revertendo de SEPARADOS para EM_SEPARACAO.

Q7: O método altera todos os pedidos da lista?
A7: Sim, desde que os pedidos estejam com o status SEPARADOS.

Q8: Qual o retorno em caso de sucesso?
A8: Um objeto ResultadoAlteracaoStatusPedidosVO com sucesso verdadeiro e mensagem informando a alteração.

Q9: Como são tratadas exceções?
A9: Exceções são capturadas e o método retorna “Erro geral : cancelar_Separados.”

Q10: É possível cancelar apenas alguns pedidos?
A10: A alteração é aplicada em lote, porém somente os pedidos com status SEPARADOS serão afetados.

Q11: Quais DAOs são utilizados nesta operação?
A11: A operação utiliza a fachada, que invoca os DAOs de pedidos conforme necessário.

Q12: Posso reexecutar o cancelamento se houver erro?
A12: Sim, desde que os pedidos estejam no status SEPARADOS e os parâmetros estejam corretos.

Q13: Como confirmar a quantidade de pedidos alterados?
A13: O objeto de resultado informa quantos pedidos tiveram seu status modificado.

Q14: Há alguma validação especial para a lista de pedidos?
A14: A lista deve ser não nula e conter pelo menos um pedido.

Q15: Qual é o cenário de uso do método cancelar_Separados?
A15: Ele é usado para reverter pedidos que já foram marcados como SEPARADOS, retornando-os para o status EM_SEPARACAO.

17. Método: cancelar_EmSeparacao

Validações do método cancelar_EmSeparacao

Acesso e Cliente: Valida a senha da central e identifica o cliente.
Status Atual: Verifica que os pedidos estão com status EM_SEPARACAO.
Chamada à Fachada: Chama o GerenciadorPedidosFachada para alterar o status para LIBERADO_PARA_SEPARACAO.

FAQ – cancelar_EmSeparacao

Q1: Quais parâmetros são obrigatórios no método cancelar_EmSeparacao?
A1: É necessário informar a lista de pedidos, CPF/CNPJ, senha do cliente e senha da central.

Q2: Qual o status atual exigido para este cancelamento?
A2: Os pedidos devem estar com status EM_SEPARACAO.

Q3: Qual é o novo status aplicado?
A3: O status é revertido para LIBERADO_PARA_SEPARACAO.

Q4: Como o método valida a senha da central?
A4: Utilizando o DAO da Empresa; se a senha for inválida, retorna “Erro: Senha invalida.”

Q5: O que ocorre se o cliente não for identificado?
A5: Retorna erro informando que o cliente não está cadastrado.

Q6: Qual a função do GerenciadorPedidosFachada aqui?
A6: Ele executa a alteração de status, revertendo de EM_SEPARACAO para LIBERADO_PARA_SEPARACAO.

Q7: O método opera em lote?
A7: Sim, ele altera o status de todos os pedidos na lista que atendem à condição.

Q8: Qual é o retorno em caso de sucesso?
A8: Um ResultadoAlteracaoStatusPedidosVO com sucesso verdadeiro e mensagem confirmando a alteração.

Q9: Como são tratadas exceções?
A9: Exceções são capturadas e o método retorna “Erro geral : cancelar_EmSeparacao.”

Q10: O que fazer se algum pedido não estiver no status EM_SEPARACAO?
A10: Somente os pedidos com o status correto serão alterados; os demais gerarão erro.

Q11: Quais DAOs são utilizados na operação?
A11: A operação é feita pela fachada que utiliza os DAOs de pedidos conforme necessário.

Q12: É possível reexecutar o cancelamento se ocorrer erro?
A12: Sim, contanto que os pedidos estejam novamente no status EM_SEPARACAO e os parâmetros estejam corretos.

Q13: Como confirmar quantos pedidos foram alterados?
A13: O objeto de resultado informa a quantidade de pedidos atualizados.

Q14: Há alguma verificação extra na lista de pedidos?
A14: Sim, a lista não pode ser nula e deve conter pelo menos um pedido.

Q15: Qual cenário de uso se aplica ao método cancelar_EmSeparacao?
A15: Ele é usado para reverter a operação de separação, retornando os pedidos para LIBERADO_PARA_SEPARACAO.

18. Método: cancelar_LiberadosSeparacao

Validações do método cancelar_LiberadosSeparacao

Acesso e Cliente: Verifica a senha da central e identifica o cliente.
Status Atual: Confirma que os pedidos estão com status LIBERADO_PARA_SEPARACAO.
Chamada à Fachada: Chama o GerenciadorPedidosFachada para alterar o status para VENDA_FINALIZADA.

FAQ – cancelar_LiberadosSeparacao

Q1: Quais parâmetros são obrigatórios no método cancelar_LiberadosSeparacao?
A1: São necessários a lista de pedidos, CPF/CNPJ, senha do cliente e senha da central.

Q2: Qual o status atual exigido para o cancelamento?
A2: Os pedidos devem estar com status LIBERADO_PARA_SEPARACAO.

Q3: Qual o novo status após o cancelamento?
A3: O status será alterado para VENDA_FINALIZADA.

Q4: Como o método valida a senha da central?
A4: A senha é validada pelo DAO da Empresa; se estiver errada, retorna “Erro: Senha invalida.”

Q5: O que acontece se o cliente não for identificado?
A5: O método retorna um erro indicando que o cliente não está cadastrado.

Q6: Qual a função do GerenciadorPedidosFachada neste método?
A6: Ele executa a alteração do status de LIBERADO_PARA_SEPARACAO para VENDA_FINALIZADA.

Q7: O método altera o status de todos os pedidos da lista?
A7: Sim, desde que todos os pedidos estejam com o status LIBERADO_PARA_SEPARACAO.

Q8: Qual é o retorno em caso de sucesso?
A8: Um objeto ResultadoAlteracaoStatusPedidosVO com sucesso verdadeiro e mensagem informando a alteração.

Q9: Como são tratadas exceções neste método?
A9: Exceções são capturadas e o método retorna “Erro geral : cancelar_LiberadosSeparacao.”

Q10: É possível cancelar parcialmente os pedidos?
A10: Apenas os pedidos que estiverem com o status correto serão alterados; os demais serão ignorados ou causarão erro.

Q11: Quais DAOs são utilizados na operação?
A11: A operação utiliza a fachada, que invoca os DAOs de pedidos conforme necessário.

Q12: Posso reexecutar o cancelamento se ocorrer erro?
A12: Sim, contanto que os pedidos estejam novamente no status LIBERADO_PARA_SEPARACAO e os parâmetros estejam corretos.

Q13: Como saber quantos pedidos foram atualizados?
A13: O objeto de resultado retorna a quantidade de pedidos cujo status foi modificado.

Q14: Há alguma verificação específica para a lista de pedidos?
A14: A lista deve ser não nula e conter ao menos um pedido, ou a operação não será realizada.

Q15: Qual é o cenário de uso do método cancelar_LiberadosSeparacao?
A15: Este método é usado para cancelar a liberação para separação, revertendo os pedidos para o status VENDA_FINALIZADA.

Considerações Finais

Cada método WebService da classe ImportadorPedidos segue um padrão de validação de acesso (senha da central e identificação do cliente) antes de executar a lógica específica de cada operação – seja conversão de CEP, importação de pedidos, consulta de status, listagens ou alterações de status. As FAQs aqui apresentadas visam responder dúvidas comuns sobre as validações, parâmetros obrigatórios e comportamentos esperados de cada método.

Você pode adaptar e complementar estas perguntas e respostas conforme a evolução do sistema ou necessidades dos usuários.

Esta documentação está formatada para ser integrada no BookStack e serve como referência completa das validações e FAQs de cada método WebService da classe ImportadorPedidos.